\begin{aosachapter}{Telepathy}{s:telepathy}{Danielle Madeley}
%% Based on EN-Revision r272

%% Telepathy\footnote{\url{http://telepathy.freedesktop.org/}, or see the
%% developers' manual at \url{http://telepathy.freedesktop.org/doc/book/}} is a
%% modular framework for real-time communications that handles voice, video, text, file
%% transfer, and so on. What's unique about Telepathy is not that it abstracts the
%% details of various instant messaging protocols, but that it provides the idea
%% of communications as a service, in much the same way that printing is a
%% service, available to many applications at once. To achieve this Telepathy
%% makes extensive use of the D-Bus messaging bus and a modular design.
Telepathy\footnote{\url{http://telepathy.freedesktop.org/}、あるいは
\url{http://telepathy.freedesktop.org/doc/book/}にある開発者向けマニュアルを参照}
はリアルタイム通信のためのモジュラーフレームワークで、音声や動画、テキスト、
ファイル転送などを扱える。Telepathyが他のフレームワークと違う点は、
さまざまなインスタントメッセージングプロトコルの詳細を抽象化しているというところではない。
サービスとしての通信(communications as a service)を提供するというアイデアこそが他との違いで、
これはちょうど印刷をサービスとして提供して多くのアプリケーションから使えるようにするという考え方と同じである。
このアイデアを実現するために、TelepathyはD-Busメッセージングバスと
モジュラー設計を幅広く活用した。

%% Communications as a service is incredibly useful, because it allows us
%% to break communications out of a single application. This enables lots
%% of interesting use cases: being able to see a contact's
%% presence in your email application; start communicating with
%% her; launching a file transfer to a contact straight from your file
%% browser; or providing contact-to-contact collaboration within
%% applications, known in Telepathy as \emph{Tubes}.
通信をサービスとして提供できると非常に便利だ。
単一のアプリケーションの枠を超えた通信ができるようになるからだ。
いろんな使い道が考えられる。たとえば、メールアプリケーション上で相手が在席中であることを確認してから
相手とのやりとりを始めたり、ファイルを転送も、ファイルブラウザから相手に直接送れたりする。
アプリケーション内でお互いに共同作業することもできる。これはTelepathy as \emph{Tubes}
(Telepathyを土管として使う)と呼ばれている。

%% Telepathy was created by Robert McQueen in 2005 and since that time
%% has been developed and maintained by several companies and individual
%% contributors including Collabora, the company co-founded by McQueen.
TelepathyはRobert McQueenが2005年に作ったものだ。
それ以降はいくつかの企業や個人で開発と保守を進めている。
その中の一社であるCollaboraは、McQueenが共同設立者の一人となっている企業である。

%% \begin{aosabox}{The D-Bus Message Bus}
\begin{aosabox}{D-Busメッセージバス}

%% D-Bus is an asynchronous message bus for interprocess communication
%% that forms the backbone of most GNU/Linux systems including the GNOME
%% and KDE desktop environments.  D-Bus is a primarily a shared bus
%% architecture: applications connect to a bus (identified by a socket
%% address) and can either transmit a targeted message to another
%% application on the bus, or broadcast a signal to all bus
%% members. Applications on the bus have a bus address, similar to an IP
%% address, and can claim a number of well-known names, like DNS names,
%% for example \code{org.freedesktop.Telepathy.AccountManager}.  All
%% processes communicate via the D-Bus daemon, which handles message
%% passing, and name registration.
D-Busはプロセス間通信用の非同期メッセージバスで、GNOMEやKDEといったデスクトップ環境を含む
ほとんどのGNU/Linuxシステムのバックボーンとなっている。
D-Busはそもそも共有バスアーキテクチャだった。
アプリケーションはソケットアドレスを指定してバスに接続し、
ターゲットメッセージをバス上の別のアプリケーションに送信したり
バス上の全メンバーにシグナルをブロードキャストしたりできる。
バス上のアプリケーションは、IPアドレスと同じような感じのバスアドレスを持つ。
また、名前を付けることもできる。DNSと同じような感じで、たとえば\code{org.freedesktop.Telepathy.AccountManager}
のようになる。すべてのプロセスがD-Busデーモン経由で通信を行う。
このデーモンが、メッセージの受け渡しや名前の登録を処理する。

%% From the user's perspective, there are two buses available on every
%% system.  The system bus is a bus that allows the user to communicate
%% with system-wide components (printers, bluetooth, hardware management,
%% etc.)  and is shared by all users on the system.  The session bus is
%% unique to that user---i.e., there is a session bus per logged-in
%% user---and is used for the user's applications to communicate with
%% each other.  When a lot of traffic is to be transmitted over the bus,
%% it's also possible for applications to create their own private bus,
%% or to create a peer-to-peer, unarbitrated bus with no
%% \code{dbus-daemon}.
ユーザーの視点で見ると、すべてのシステムにはふたつのバスが存在する。
ひとつはシステムバスで、これはユーザーがシステム全体のコンポーネント
(プリンタやBluetooth、ハードウェア管理など)と通信できるようにするためのバスである。
システム上のすべてのユーザーが共有する。
もうひとつはセッションバスで、これは各ユーザーに固有のものである
(つまり、システムにログインしているユーザーの数だけセッションバスが存在する)。
これは、そのユーザーが使うアプリケーションどうしがお互いに通信するために使う。
セッションバス上に大量のトラフィックが流れている場合は、
アプリケーションが自前のプライベートバスを作ることもできる。
あるいは、\code{dbus-daemon}を介さないピアツーピアのバスを作ることもできる。

%% Several libraries implement the D-Bus protocol and can communicate
%% with the D-Bus daemon, including libdbus, GDBus, QtDBus, and
%% python-dbus. These libraries are responsible for sending and receiving
%% D-Bus messages, marshalling types from the language's type system into
%% D-Bus' type format and publishing objects on the bus.  Usually, the
%% libraries also provide convenience APIs for listing connected
%% applications and activatable applications, and requesting well-known
%% names on the bus.  At the D-Bus level, all of these are done by making
%% method calls on an object published by \code{dbus-daemon} itself.
D-Busプロトコルを実装してD-Busデーモンと通信できるようにしたライブラリがいくつか存在する。
libdbusやGDBus、QtDBus、そしてpython-dbusなどだ。これらのライブラリの役割は、
D-Busメッセージの送受信だけでなく各言語の型システムからD-Busの型フォーマットへの変換や
バス上のオブジェクトの公開などもある。
これらのライブラリは、便利なAPIを提供していることも多い。
接続中のアプリケーションの一覧やアクティベート可能なアプリケーションの一覧を表示したり、
バス上での名前を取得したりするためのAPIである。
D-Busレベルでは、これらすべての操作は\code{dbus-daemon}自身が公開するオブジェクト上での
メソッド呼び出しで行う。

%% For more information on D-Bus, see
%% \url{http://www.freedesktop.org/wiki/Software/dbus}.
D-Busについての詳細は\url{http://www.freedesktop.org/wiki/Software/dbus}
を参照してほしい。

\end{aosabox}

%% \begin{aosasect1}{Components of the Telepathy Framework}
\begin{aosasect1}{Telepathy Frameworkのコンポーネント}

%% Telepathy is modular, with each module communicating with the others
%% via a D-Bus messaging bus. Most usually via the user's session bus. This
%% communication is detailed in the Telepathy
%% specification\footnote{\url{http://telepathy.freedesktop.org/spec/}}.
%% The components of the Telepathy framework are as shown in
%% \aosafigref{fig.telepathy.components}:
Telepathyはモジュラー構造で、各モジュール間の通信にはD-Busメッセージングバスを使う。
たいていの場合は、ユーザーのセッションバスである。通信の詳細は
Telepathyの仕様\footnote{\url{http://telepathy.freedesktop.org/spec/}}を参照して欲しい。
Telepathyフレームワークのコンポーネント群を\aosafigref{fig.telepathy.components}に示す。

\begin{aosaitemize}

  %% \item A Connection Manager provides the interface between Telepathy
  %%   and the individual communication services. For instance, there is
  %%   a Connection Manager for XMPP, one for SIP, one for IRC, and so
  %%   on.  Adding support for a new protocol to Telepathy is simply a
  %%   matter of writing a new Connection Manager.
  \item Connection Managerは、Telepathyと個々の通信サービスとの間のインターフェイスを提供する。
  たとえばXMPP用のConnection ManagerもあればSIP用やIRC用などのConnection Managerもあるという具合だ。
  Telepathyで新たなプロトコルに対応しようと思ったら、単にそのプロトコル用のConnection Managerを書けばよい。

  %% \item The Account Manager service is responsible for storing the
  %%   user's communications accounts and establishing a connection to
  %%   each account via the appropriate Connection Manager when
  %%   requested.
  \item Account Managerは、ユーザーの通信用アカウントを格納して各クライアントとの接続を確立する。
  その際に、リクエストがあれば適切なConnection Managerを利用する。

  %% \item The Channel Dispatcher's role is to listen for incoming
  %%   channels signalled by each Connection Manager and dispatch them to
  %%   clients that indicate their ability to handle that type of
  %%   channel, such as text, voice, video, file transfer, tubes.  The
  %%   Channel Dispatcher also provides a service so that applications,
  %%   most importantly applications that are not Telepathy clients, can
  %%   request outgoing channels and have them handled locally by the
  %%   appropriate client. This allows an application, such as an email
  %%   application, to request a text chat with a contact, and have your
  %%   IM client show a chat window.
  \item Channel Dispatcherの役割は、各Connection Managerからの入力チャネルをリスンして
  チャネルの型(テキストや音声、動画、ファイル転送、チューブなど)に応じてそれを処理できるクライアントに振り分ける。
  Channel Dispatcherは、それ以外にもサービスを提供する。
  さまざまなアプリケーション、特にTelepathyクライアントではないアプリケーションから
  出力チャネルにリクエストできるようにして、それをローカルの適切なクライアントで処理させるサービスだ。
  これを使えば、メールソフトなどのアプリケーションがテキストチャットのリクエストを出せるようになり、
  リクエストがあれば、IMクライアントがチャットウィンドウを表示することになる。

  %% \item Telepathy clients handle or observe communications
  %%   channels. They include both user interfaces like IM and VoIP
  %%   clients and services such the chat logger. Clients register
  %%   themselves with the Channel Dispatcher, giving a list of channel
  %%   types they wish to handle or observe.
  \item Telepathyクライアントは、通信チャネルを処理したり監視したりする。
  IMやVoIPクライアントのようなユーザーインターフェイスだけでなく、チャットのロガーのようなサービスも含む。
  クライアントは自分自身をChannel Dispatcherに登録し、自分が処理したいチャネルタイプを伝える。

\end{aosaitemize}

%% Within the current implementation of Telepathy, the Account Manager
%% and the Channel Dispatcher are both provided by a single process known
%% as Mission Control.
現在のTelepathyの実装では、Account ManagerとChannel Dispatcherは
ひとつのプロセスで提供している。このプロセスのことをMission Controlと呼ぶ。

%% \aosafigureTop[250pt]{../images/telepathy/telepathy-components.eps}{Example Telepathy Components}{fig.telepathy.components}
\aosafigureTop[250pt]{../images/telepathy/telepathy-components.eps}{Telepathyコンポーネントの例}{fig.telepathy.components}

%% This modular design was based on Doug McIlroy's philosophy, ``Write
%% programs that do one thing and do it well,'' and has several important
%% advantages:
このモジュラー設計は、Doug McIlroyの哲学「一つのことを行い、またそれをうまくやるプログラムを書け」
に基づいたもので、次のような利点がある。

\pagebreak

\begin{aosadescription}

  %% \item{Robustness:} a fault in one component won't crash the
  %% entire service.
  \item{ロバストネス:}どれかひとつのコンポーネントに障害が発生しても、サービス全体がクラッシュすることはない。

  %% \item{Ease of development:} components can be replaced within
  %% a running system without affecting others. It's possible to test a
  %% development version of one module against another known to be
  %% good.
  \item{開発のしやすさ:}稼働中のシステムのコンポーネントを差し替えたとしても、他の箇所には影響しない。
  開発版のモジュールを、動作検証済みの他のモジュールと組み合わせてテストすることもできる。

  %% \item{Language independence:} components can be written in any
  %% language that has a D-Bus binding. If the best
  %% implementation of a given communications protocol is in a certain
  %% language, you are able to write your Connection Manager in that
  %% language, and still have it available to all Telepathy clients.
  %% Similarly, if you wish to develop your user interface in a certain
  %% language, you have access to all available protocols.
  \item{言語非依存:}コンポーネントは、D-Busバインディングがありさえすればどんな言語でも書ける。
  もし何かの通信プロトコル用の実装としてすぐれたものが何かの言語で用意されているのなら、
  Connection Managerをその言語で書けばよい。他の言語で書いたものも含め、すべてのTelepathyクライアントからそれを使うことができる。
  同様に、何か特定の言語でユーザーインターフェイスを作れば、そこからすべてのプロトコルにアクセスできる。

  %% \item{License independence:} components can be under different
  %% software licenses that would be incompatible if everything was
  %% running as one process.
  \item{ライセンス非依存:}自分で作ったコンポーネントを、まったく別のライセンスで公開することもできる。
  すべてがひとつのプロセスの場合だと非互換になってしまうようなライセンスでも、だいじょうぶだ。

  %% \item{Interface independence:} multiple user interfaces can be
  %% developed on top of the same Telepathy components. This allows native
  %% interfaces for desktop environments and hardware devices
  %% (e.g., GNOME, KDE, Meego, Sugar).
  \item{インターフェイス非依存:}同じTelepathyコンポーネントに対して複数のユーザーインターフェイスを開発できる。
  デスクトップ環境やハードウェアデバイス(GNOMEやKDE、Meego、Sugarなど)ごとにネイティブインターフェイスを用意できるということだ。

  %% \item{Security:} Components run in separate address spaces and
  %% with very limited privileges.  For example, a typical
  %% Connection Manager only needs access to the network and the D-Bus
  %% session bus, making it possible to use something like SELinux to
  %% limit what a component can access.
  \item{セキュリティ:}コンポーネントは個別のアドレス空間で動作し、限られた権限しか持たない。
  たとえば、一般的なConnection Managerが必要な権限はネットワークへのアクセスと
  D-Busセッションバスへのアクセスだけである。それを実現するために、SELinux風の仕組みを使って
  そのコンポーネントがアクセスできる範囲を制限している。

\end{aosadescription}

%% The Connection Manager manages a number of Connections, where each
%% Connection represents a logical connection to a communications
%% service. There is one Connection per configured account.
%% A Connection will contain multiple Channels. Channels are the
%% mechanism through which communications are carried out. A channel
%% might be an IM conversation, voice or video call, file transfer or
%% some other stateful operation.  Connections and channels are discussed
%% in detail in \aosasecref{sec.telepathy.ccc}.
Connection Managerはコネクションを管理し、各コネクションは通信サービスへの論理的な接続を表す。
設定済みのアカウントごとにひとつのコネクションが存在する。
ひとつのコネクションには複数のチャネルが含まれる。
チャネルとは、通信を運ぶ仕組みである。
チャネルは、IMの会話や音声通信、映像通信、ファイル転送などのステートフルな操作となる。
コネクションとチャネルの詳細については\aosasecref{sec.telepathy.ccc}で説明する。

\end{aosasect1}

%% \begin{aosasect1}{How Telepathy uses D-Bus}
\begin{aosasect1}{TelepathyによるD-Busの利用法}

%% Telepathy components communicate via a D-Bus messaging bus, which is
%% usually the user's session bus.  D-Bus provides features common to
%% many IPC systems: each service publishes objects which have
%% a strictly namespaced object path, like
%% \code{/org/freedesktop/Telepathy/AccountManager}\footnote{From here
%% on, \code{/org/freedesktop/Telepathy/} and
%% \code{org.freedesktop.Telepathy} will be abbreviated to \code{ofdT}
%% to save space.}.  Each object implements a number of
%% interfaces. Again strictly namespaced, these have forms like
%% \code{org.freedesktop.DBus.Properties} and \code{ofdT.Connection}.
%% Each interface provides methods, signals and properties that you can
%% call, listen to, or request.
TelepathyコンポーネントはD-Busメッセージングバスを使って通信する。通常はユーザーのセッションバスだ。
D-Busが提供する機能は、他のプロセス間通信システムにもよくあるものだ。
各サービスはオブジェクトを公開し、それぞれがきちんと名前空間に分けられたオブジェクトパスを持つ。
たとえば\code{/org/freedesktop/Telepathy/AccountManager}
\footnote{これ以降は、\code{/org/freedesktop/Telepathy/}や\code{org.freedesktop.Telepathy}を\code{ofdT}と略記する。}
のようなものだ。各オブジェクトはさまざまなインターフェイスを実装する。
これもまたきちんと名前空間に分かれており、
\code{org.freedesktop.DBus.Properties}や\code{ofdT.Connection}
のような形式になる。それぞれのインターフェイスが、メソッドやシグナルそしてプロパティを提供する。
これらを呼んだりリスンしたりリクエストしたりするわけだ。

%% \aosafigure{../images/telepathy/bus-hierarchy-conceptual.eps}{Conceptual Representation of Objects Published by a D-Bus Service}{fig.telepathy.conceptual}
\aosafigure{../images/telepathy/bus-hierarchy-conceptual.eps}{D-Busサービスが公開するオブジェクトの概念表現}{fig.telepathy.conceptual}

%% \begin{aosabox}{Publishing D-Bus Objects}
\begin{aosabox}{D-Busオブジェクトの公開}

%% Publishing D-Bus objects is handled entirely by the D-Bus library
%% being used. In effect it is a mapping from a D-Bus object path to the
%% software object implementing those interfaces.  The paths of objects
%% being published by a service are exposed by the optional
%% \code{org.freedesktop.DBus.Introspectable} interface.
D-Busオブジェクトの公開は、使っているD-Busライブラリが全体を担当する。
実際は、D-Busオブジェクトのパスとそのインターフェイスを実装するソフトウェアオブジェクトとのマッピングである。
サービスが公開するオブジェクトのパスは、オプションの\code{org.freedesktop.DBus.Introspectable}
インターフェイスで公開する。

%% When a service receives an incoming method call with a given
%% destination path (e.g., \code{/ofdT/AccountManager}), the D-Bus
%% library is responsible for locating the software object providing that
%% D-Bus object and then making the appropriate method call on that
%% object.
あるサービスが、指定したパス(\code{/ofdT/AccountManager}など)からのメソッド呼び出しを受け取ると、
D-BusライブラリがそのD-Busオブジェクトを提供するソフトウェアオブジェクトの場所を探し、それに対して適切なメソッド呼び出しを行う。

\end{aosabox}

%% The interfaces, methods, signal and properties provided by Telepathy
%% are detailed in an XML-based D-Bus IDL that has been expanded to
%% include more information.  The specification can be parsed to generate
%% documentation and language bindings.
Telepathyが提供するインターフェイスやメソッド、シグナル、そしてプロパティは
XMLベースのD-Bus IDLで詳述される。それだけでなく、ここにはより詳細な情報も含まれている。
この仕様をパースして、ドキュメントを生成したり言語バインディングを生成したりできる。

%% Telepathy services publish a number of objects onto the bus. Mission
%% Control publishes objects for the Account Manager and Channel
%% Dispatcher so that their services can be accessed. Clients publish a
%% Client object that can be accessed by the Channel Dispatcher. Finally,
%% Connection Managers publish a number of objects: a service object that
%% can be used by the Account Manager to request new connections, an
%% object per open connection, and an object per open channel.
Telepathyサービスは、さまざまなオブジェクトをバス上に公開する。
Mission Controlが公開するのはAccount ManagerやChannel Dispatcher用のオブジェクトで、
これを使えばそれぞれのサービスにアクセスできるようになる。
クライアントが公開するのはClientオブジェクトで、これを使えばChannel Dispatcher
からクライアントにアクセスできるようになる。
最後に、Connection Managersもいくつかのオブジェクトを公開する。
Account Managerが新たなコネクションを要求するために使うサービスオブジェクトや
各コネクションに対応するオブジェクト、そしてチャネルに対応するオブジェクトなどだ。

%% Although D-Bus objects do not have a type (only interfaces), Telepathy
%% simulates types several ways. The object's path tells us whether the
%% object is a connection, channel, client, and so on, though generally
%% you already know this when you request a proxy to it. Each object
%% implements the base interface for that type, e.g.,
%% \code{ofdT.Connection} or \code{ofdT.Channel}.  For channels this is
%% sort of like an abstract base class.  Channel objects then have a
%% concrete class defining their channel type.  Again, this is
%% represented by a D-Bus interface. The channel type can be learned by
%% reading the \code{ChannelType} property on the Channel interface.
D-Busバスオブジェクトは型を持たない(インターフェイスしか持たない)が、
Telepathyはいくつかの方法で型をシミュレートする。
オブジェクトのパスを見れば、そのオブジェクトがコネクションなのかチャネルなのかクライアントなのかといったことはわかる。
しかし普通は、プロキシにオブジェクトをリクエストした時点で既にそのパスを知っているはずだ。
各オブジェクトは、その型に合わせた基底インターフェイスを実装している。\code{ofdT.Connection}や\code{ofdT.Channel}
といったものだ。チャネルにとっては、これは一種の抽象基底クラスのようなものになる。
Channelオブジェクトはそのチャネルの型を定義する具象クラスを持つことになる。
改めて言うが、これはD-Busのインターフェイスで表されるものだ。
チャネルの型について知るには、Channelインターフェイスの\code{ChannelType}プロパティを読めばよい。

%% Finally, each object implements a number of optional interfaces
%% (unsurprisingly also represented as D-Bus interfaces), which depend on
%% the capabilities of the protocol and the Connection Manager.  The
%% interfaces available on a given object are available via the
%% \code{Interfaces} property on the object's base class.
最後にもうひとつ。各オブジェクトはオプションのインターフェイスも実装している
(言うまでもなく、これらもまたD-Busのインターフェイスだ)。
これらは、そのプロトコルやConnection Managerの機能に依存する。
あるオブジェクトで使えるインターフェイスを知るには、
そのオブジェクトの基底クラスの\code{Interfaces}プロパティを調べればよい。

%% For Connection objects of type \code{ofdT.Connection}, the optional
%% interfaces have names like \code{ofdT.Connection.Interface.Avatars}
%% (if the protocol has a concept of avatars),
%% \path{odfT.Connection.Interface.ContactList} (if the protocol provides
%% a contact roster---not all do) and
%% \path{odfT.Connection.Interface.Location} (if a protocol provides
%% geolocation information).  For Channel objects, of type
%% \path{ofdT.Channel}, the concrete classes have interface names of the
%% form \path{ofdT.Channel.Type.Text}, \path{odfT.Channel.Type.Call} and
%% \path{odfT.Channel.Type.FileTransfer}. Like Connections, optional
%% interface have names likes \path{odfT.Channel.Interface.Messages} (if
%% this channel can send and receive text messages) and
%% \path{odfT.Channel.Interface.Group} (if this channel is to a group
%% containing multiple contacts, e.g., a multi-user chat).  So, for
%% example, a text channel implements at least the \path{ofdT.Channel},
%% \path{ofdT.Channel.Type.Text} and \path{Channel.Interface.Messages}
%% interfaces.  If it's a multi-user chat, it will also implement
%% \path{odfT.Channel.Interface.Group}.
\code{ofdT.Connection}型のConnectionオブジェクトの場合、オプションのインターフェイスの名前は
\code{ofdT.Connection.Interface.Avatars} (アバターの概念を持つプロトコルの場合)や
\path{odfT.Connection.Interface.ContactList} (連絡先名簿を提供するプロトコルの場合---そうでないものもある)
そして\path{odfT.Connection.Interface.Location} (位置情報を提供するプロ所ルの場合)となる。
\path{ofdT.Channel}型のChannelオブジェクトの場合は、具象クラスが持つインターフェイスの名前は
\path{ofdT.Channel.Type.Text}や\path{odfT.Channel.Type.Call}そして\path{odfT.Channel.Type.FileTransfer}
といった形式になる。コネクションの場合と同様、オプションのインターフェイスの名前は
\path{odfT.Channel.Interface.Messages} (このチャネルでテキストメッセージの送受信ができる場合)や
\path{odfT.Channel.Interface.Group} (このチャネルの相手が複数の連絡先を含むグループ、たとえばマルチユーザーチャットである場合)
のようになる。つまり、たとえばテキストチャネルの場合は、少なくとも
\path{ofdT.Channel}と\path{ofdT.Channel.Type.Text}そして\path{Channel.Interface.Messages}
インターフェイスを実装していることになる。もしそのチャネルがマルチユーザーチャットであるなら、
さらに\path{odfT.Channel.Interface.Group}も実装しているわけだ。

%% \begin{aosabox}{Why an Interfaces Property and not D-Bus Introspection?}
\begin{aosabox}{D-BusイントロスペクションがあるのになぜInterfacesプロパティなのか}

%% You might wonder why each base class implements an \code{Interfaces}
%% property, instead of relying on D-Bus' introspection capabilities to
%% tell us what interfaces are available.  The answer is that different
%% channel and connection objects may offer different interfaces to each
%% other, depending on the capabilities of the channel or connection, but
%% that most of the implementations of D-Bus introspection assume that
%% all objects of the same object class will have the same interfaces.
%% For example, in \code{telepathy-glib}, the D-Bus interfaces listed by
%% D-Bus introspection are retrieved from the object interfaces a class
%% implements, which is statically defined at compile time.  We work
%% around this by having D-Bus introspection provide data for all the
%% interfaces that could exist on an object, and use the
%% \code{Interfaces} property to indicate which ones actually do.
なぜわざわざ各基底クラスが\code{Interfaces}プロパティを実装しているのだろう？
D-Busのイントロスペクション機能を使えばどんなインターフェイスがあるかはわかるはずなのに。
その理由を説明する。
さまざまなチャネルやコネクションオブジェクトはそれぞれ異なるインターフェイスを持つ可能性があり、
それはチャネルやコネクションの機能に依存している。
しかしD-Busのイントロスペクション機能の大半は、同じクラスのオブジェクトはすべて
同じインターフェイスを持つことを前提としている。
たとえば\code{telepathy-glib}では、D-Busのイントロスペクションが列挙する
D-Busインターフェイスはそのクラスが実装するオブジェクトのインターフェイスから取得したものであり、
コンパイル時に静的に決まるものである。
私たちはこの問題を解決するために、
D-Busのイントロスペクションがオブジェクトに存在しないものも含めてすべてのインターフェイスのデータを提供させるようにした。
そして、\code{Interfaces}プロパティを使って実際に動くものがどれなのかを示すようにした。

\end{aosabox}

%% Although D-Bus itself provides no sanity checking that connection
%% objects only have connection-related interfaces and so forth (since
%% D-Bus has no concept of types, only arbitrarily named interfaces), we
%% can use the information contained within the Telepathy specification
%% to provide sanity checking within the Telepathy language bindings.
D-Bus自体には、コネクションオブジェクトがコネクション関係のインターフェイスだけしか持っていないことを確認する手段がない
(というのもD-Busには型という概念がなく、任意の名前のインターフェイスがあるだけだからである)。
しかし、Telepathyの仕様に含まれる情報を使えば、Telepathyの言語バインディングの中で
そのチェックはできる。

%% \begin{aosabox}{Why and How the Specification IDL was Expanded}
\begin{aosabox}{なぜ、そしてどうやってSpecification IDLを展開するのか}

%% The existing D-Bus specification IDL defines the names, arguments,
%% access restrictions and D-Bus type signatures of methods, properties
%% and signals. It provides no support for documentation, binding hints
%% or named types.
既存のD-Bus specification IDLで定義されているのは名前や引数そしてアクセス制御の他には
メソッドやプロパティそしてシグナルのD-Bus型シグネチャである。
ドキュメンテーションやバインドヒントあるいは型の名前などには対応していない。

%% To resolve these limitations, a new XML namespace was added to provide
%% the required information. This namespace was designed to be generic so
%% that it could be used by other D-Bus APIs. New elements were added to
%% include inline documentation, rationales, introduction and deprecation
%% versions and potential exceptions from methods.
この制約を解決するために、新たなXML名前空間を追加して必要な情報を提供することにした。
この名前空間は汎用的に作られている。他のD-Bus APIからも使えるようにするためだ。
新たに追加された要素を使えば、インラインドキュメントや論理的な意味、
簡単な解説、廃止予定のバージョン、発生しうる例外などといった情報をメソッドに含められるようになる。

%% D-Bus type signatures are the low-level type notation of what is
%% serialized over the bus. A D-Bus type signature may look like
%% \code{(ii)} (which is a structure containing two int32s), or it may be
%% more complex.  For example, \code{a\{sa(usuu)\}}, is a map from string
%% to an array of structures containing uint32, string, uint32, uint32
%% (\aosafigref{fig.telepathy.dbustypes}).  These types, while
%% descriptive of the data format, provide no semantic meaning to the
%% information contained in the type.
D-Busの型シグネチャは低レベルの型記法であり、バス上で何がシリアライズされるのかを表している。
D-Busの型シグネチャは\code{(ii)} (これは、ふたつのint32を含む構造体を表す)
のようなものだったり、あるいはもう少し複雑なものだったりする。
たとえば\code{a\{sa(usuu)\}}は文字列から構造体の配列へのマップで、
その構造にはuint32、string、uint32そしてuint32が含まれる(\aosafigref{fig.telepathy.dbustypes})。
これらの型情報にはデータフォーマットについての説明しか含まれておらず、
その型に含まれる情報の意味はまったくわからない。

%% In an effort to provide semantic clarity for programmers and
%% strengthen the typing for language bindings, new elements were added
%% to name simple types, structs, maps, enums, and flags, providing their
%% type signature, as well as documentation.  Elements were also added in
%% order to simulate object inheritance for D-Bus objects.
プログラマーにとっての意味を明確にして言語バインディングの型付けを強化するために、
新たな要素が追加された。単純な型や構造体、マップ、列挙型、フラグなどについて、
その型シグネチャだけでなくドキュメンテーションも提供できるようにしたのだ。
また、D-Busオブジェクトでのオブジェクト継承をシミュレートするための要素も追加された。

\end{aosabox}

%% \aosafigure[250pt]{../images/telepathy/telepathy-types-unpacked.eps}{D-Bus Types (ii) and a\{sa(usuu)\}}{fig.telepathy.dbustypes}
\aosafigure[250pt]{../images/telepathy/telepathy-types-unpacked.eps}{D-Busの(ii)型およびa\{sa(usuu)\}型}{fig.telepathy.dbustypes}

%% \begin{aosasect2}{Handles}
\begin{aosasect2}{ハンドル}

%% Handles are used in Telepathy to represent identifiers (e.g., contacts
%% and room names). They are an unsigned integer value assigned by the
%% connection manager, such that the tuple (connection, handle type,
%% handle) uniquely refers to a given contact or room.
ハンドルは、Telepathyの中での識別子(連絡先やルーム名など)として利用される。
Connection Managerが割り当てる符号なし整数値で、タプル
(connection, handle type, handle)で連絡先やルームを一意に特定できる。

\pagebreak

%% Because different communications protocols normalize identifiers in
%% different ways (e.g., case sensitivity, resources), handles provide a
%% way for clients to determine if two identifiers are the same. They can
%% request the handle for two different identifiers, and if the handle
%% numbers match, then the identifiers refer to the same contact or room.
通信プロトコルによって識別子の正規化の方法が違う(大文字小文字の区別やリソースの扱いなど)
ので、クライアント側からふたつの識別子が一致するかどうかを知る方法をハンドルが提供する。
異なるふたつの識別子のハンドルをリクエストして、もし両方のハンドル番号が一致していれば
そのふたつの識別子は同じ連絡先あるいはルームを指していることになる。

%% Identifier normalization rules are different for each protocol, so it
%% is a mistake for clients to compare identifier strings to compare
%% identifiers. For example, \code{escher@tuxedo.cat/bed} and
%% \code{escher@tuxedo.cat/litterbox} are two instances of the same
%% contact (\code{escher@tuxedo.cat}) in the XMPP protocol, and therefore
%% have the same handle. It is possible for clients to request channels
%% by either identifier or handle, but they should only ever use handles
%% for comparison.
プロトコルによって識別子の正規化ルールは違うのだから、
クライアント側で識別子の文字列を使った比較をしても無意味だ。
たとえば\code{escher@tuxedo.cat/bed}と\code{escher@tuxedo.cat/litterbox}
は、XMPPプロトコルではどちらも同じ連絡先(\code{escher@tuxedo.cat})
を表すふたつのインスタンスとなる。つまりこれらふたつのハンドルは一致する。
クライアント側からは、チャネルに対して識別子を要求することもできるし
ハンドルを要求することもできる。しかし、
比較に使えるのはハンドルだけであることに注意。

\end{aosasect2}

%% \begin{aosasect2}{Discovering Telepathy Services}
\begin{aosasect2}{Telepathyサービスの検出}

%% Some services, such as the Account Manager and the Channel Dispatcher,
%% which always exist, have well known names that are defined in the
%% Telepathy specification. However, the names of Connection Managers and
%% clients are not well-known, and must be discovered.
Account ManagerやChannel Dispatcherなど、サービスによっては常に存在するものもあり、
これらについてはTelepathyの仕様で名前が定義されている。しかし
Connection Managersやクライアントには既知の名前がないので、使うときにはサービスを探す必要がある。

%% There's no service in Telepathy responsible for the registration of
%% running Connection Managers and Clients. Instead, interested parties
%% listen on the D-Bus for the announcement of a new service.  The D-Bus
%% bus daemon will emit a signal whenever a new named D-Bus service
%% appears on the bus. The names of Clients and Connection Managers begin
%% with known prefixes, defined by the specification, and new names can
%% be matched against these.
Telepathyには、稼働中のConnection Managersやクライアントの登録を受け持つサービスはない。
その代わりに、D-Bus上に新たなサービスが現れたときのアナウンスを聞いて調べることになる。
D-Busバスデーモンは、新たなD-Busサービスがバス上に登場するたびにシグナルを発行する。
クライアントやConnection Managersの名前は使用で定義されたプレフィックスから始まるので、
新たな名前をこのプレフィックスとマッチさせて調べることができる。

%% The advantage of this design is that it's completely stateless. When a
%% Telepathy component is starting up, it can ask the bus daemon (which
%% has a canonical list, based on its open connections) what services are
%% currently running.  For instance, if the Account Manager crashes, it
%% can look to see what connections are running, and reassociate those
%% with its account objects.
この方式のメリットは、完全にステートレスであることだ。
Telepathyコンポーネントが立ち上がるときに、バスデーモン
(コネクションが開いているときには、正式な一覧がある)
に対してどんなサービスが稼働中なのかを問い合わせることができる。
たとえば仮にAccount Managerがクラッシュした場合、
いまどんなコネクションが稼働中なのかを確認してそれをアカウントオブジェクトと再びつなげることができる。

%% \begin{aosabox}{Connections are Services Too}
\begin{aosabox}{コネクションもまたサービス}

%% As well as the Connection Managers themselves, the connections are
%% also advertised as D-Bus services. This hypothetically allows for the
%% Connection Manager to fork each connection off as a separate process,
%% but to date no Connection Manager like this has been implemented.
%% More practically, it allows all running connections to be discovered
%% by querying the D-Bus bus daemon for all services beginning with
%% \code{ofdT.Connection}.
Connection Managers自身と同様、コネクションもまたD-Busのサービスとなる。
この前提だと、Connection Managerは各コネクションを個別のプロセスとしてフォークできるようになる。
しかし現時点では、そんな実装のConnection Managerは存在しない。
より現実的な手段として、すべての稼働中のコネクションを調べるときには
D-Busバスデーモンに対して\code{ofdT.Connection}ではじまるすべてのサービスを問い合わせる。

\end{aosabox}

%% The Channel Dispatcher also uses this method to discover Telepathy
%% clients. These begin with the name \code{ofdT.Client}, e.g.,
%% \code{ofdT.Client.Logger}.
Channel Dispatcherもこの方式を使ってTelepathyクライアントを探す。
クライアントの名前は\code{ofdT.Client}ではじまり、たとえば\code{ofdT.Client.Logger}のようになる。

\end{aosasect2}

%% \begin{aosasect2}{Reducing D-Bus Traffic}
\begin{aosasect2}{D-Busトラフィックの軽減}

%% Original versions of the Telepathy specification created an excessive
%% amount of D-Bus traffic in the form of method calls requesting
%% information desired by lots of consumers on the bus. Later versions of
%% the Telepathy have addressed this through a number of optimizations.
最初のTelepathyの仕様は、大量のD-Busトラフィックが発生するものだった。
メソッドを呼ぼうとすると、バス上の大量のコンシューマーが必要とする情報をリクエストすることになったのだ。
その後のバージョンで、Telepathyはこれに対処するためにさまざまな最適化を施した。

%% Individual method calls were replaced by D-Bus properties. The
%% original specification included separate method calls for object
%% properties: \code{GetInterfaces}, \code{GetChannelType},
%% etc. Requesting all the properties of an object required several
%% method calls, each with its own calling overhead. By using D-Bus
%% properties, everything can be requested at once using the standard
%% \code{GetAll} method.
個々のメソッド呼び出しはD-Busのプロパティに置き換えられた。
当初の仕様では、オブジェクトのプロパティごとに\code{GetInterfaces}や\code{GetChannelType}
といった個別のメソッドがあったのだ。オブジェクトのすべてのプロパティを取得したければ
メソッド呼び出しが何回も発生し、そのたびに呼び出しのオーバーヘッドが発生することになる。
D-Busのプロパティを使うことで、すべてのプロパティを取得するには
標準の\code{GetAll}メソッドを一度使うだけでいいことになった。

%% Furthermore, quite a number of properties on a channel are immutable
%% for the lifetime of the channel. These include things like the
%% channel's type, interfaces, who it's connected to and the requestor.
%% For a file transfer channel, for example, it also includes things like
%% the file size and its content type.
さらに、チャネル上のプロパティの大半は、そのチャネルの活動中は不変なものだ。
チャネルの型やインターフェイス、接続先、リクエスト元などがその一例である。
たとえばファイル転送チャネルなら、それ以外にもファイルサイズやコンテントタイプなども含まれる。

%% A new signal was added to herald the creation of channels (both
%% incoming and in response to outgoing requests) that includes a hash
%% table of the immutable properties.  This can be passed directly to the
%% channel proxy constructor (see \aosasecref{sec.telepathy.readiness}),
%% which saves interested clients from having to request this information
%% individually.
チャネル(入力側もリクエストの送出側も)の作成を事前に通知するシグナルが追加され、
不変なプロパティ用のハッシュテーブルもそこに含むようにした。
これはチャネルプロキシのコンストラクタ(\aosasecref{sec.telepathy.readiness}を参照)
に直接渡せて、これを使えば各クライアントが個別に情報をリクエストせずに済むようになる。

%% User avatars are transmitted across the bus as byte arrays. Although
%% Telepathy already used tokens to refer to avatars, allowing clients to
%% know when they needed a new avatar and to save downloading unrequired
%% avatars, each client had to individually request the avatar via a
%% \code{RequestAvatar} method that returned the avatar as its reply.
%% Thus, when the Connection Manager signalled that a contact had updated
%% its avatar, several individual requests for the avatar would be made,
%% requiring the avatar to be transmitted over the message bus several
%% times.
ユーザーのアバターがバス上を通るときには、バイト配列形式になる。
Telepathyは既にアバターを参照するトークンを使っており、
それを見れば新たなアバターをダウンロードする必要があるかどうかを判断できた。
不要なダウンロードの手間はこれで省けていたが、アバターをダウンロードするときには
各クライアントが個別に\code{RequestAvatar}メソッドを呼ぶ必要があった。
このメソッドは、アバターを返すものだ。つまり、ある連絡先がアバターを更新したと
Connection Managerが通知すると、そのアバターを取得しようとするリクエストがあちこちから別々に発生し、
メッセージバス上を同じアバターが複数回転送されることになっていた。

%% This was resolved by adding a new method which did not return the
%% avatar (it returns nothing). Instead, it placed the avatar in a
%% request queue.  Retrieving the avatar from the network would result in
%% a signal, \code{AvatarRetrieved}, that all interested clients could
%% listen to. This means the avatar data only needs to be transmitted
%% over the bus once, and will be available to all the interested
%% clients. Once the client's request was in the queue, all further
%% client requests can be ignored until the emission of the
%% \code{AvatarRetrieved}.
これを解決するために新たなメソッドを追加した。このメソッドはアバターを返さない(何も返さない)。
そのかわりに、アバターをリクエストキューに追加する。
アバターをネットワークから取得すると\code{AvatarRetrieved}
シグナルが発生する。各クライアントは、このシグナルを待ち受けることができる。
これはつまり、アバターのデータがバス上で転送されるのは一度だけで済むということだ。
それ以降は、すべてのクライアントがそのアバターを使えるようになる。
あるクライアントのリクエストがキューに入れば、
それ以降のクライアントからのリクエストは\code{AvatarRetrieved}
が発行されるまでは無視される。

%% Whenever a large number of contacts need to be loaded (i.e., when
%% loading the contact roster), a significant amount of information needs
%% to be requested: their aliases, avatars, capabilities, and group
%% memberships, and possibly their location, address, and telephone numbers.
%% Previously in Telepathy this would require one method call per
%% information group (most API calls, such as \code{GetAliases} already
%% took a list of contacts), resulting in half a dozen or more method calls.
たくさんの連絡先を読み込む必要がある場合(連絡先一覧を読み込む場合など)は、
大量の情報をリクエストしなければいけない。エイリアス、アバター、所属グループ、
位置、アドレス、電話番号などである。かつてのTelepathyでは
情報グループごとに個別のメソッド呼び出しが必要で
(\code{GetAliases}など大半のAPIは既に連絡先リストを受け取るようになっていた)、
その結果、10回近くもメソッド呼び出しが発生した。

%% To solve this, the \code{Contacts} interface was introduced.  It
%% allowed information from multiple interfaces to be returned via a
%% single method call. The Telepathy specification was expanded to
%% include Contact Attributes: namespaced properties returned by the
%% \code{GetContactAttributes} method that shadowed method calls used to
%% retrieve contact information. A client calls
%% \code{GetContactAttributes} with a list of contacts and interfaces it
%% is interested in, and gets back a map from contacts to a map of
%% contact attributes to values.
これを解決するために\code{Contacts}インターフェイスを導入した。
そのおかげで、複数のインターフェイスからの情報を一度のメソッド呼び出しで返せるようになった。
Telepathyの仕様は拡張され、連絡先の属性も含むようになった。\code{GetContactAttributes}
メソッドが返す名前空間付きのプロパティが、連絡先情報を取得するために使うメソッド呼び出しを覆い隠したのだ。
クライアントは、\code{GetContactAttributes}を呼ぶときに
連絡先一覧と知りたいインターフェイスを渡す。そして、属性と値とのマップを連絡先と関連づけたマップを取得する。

%% A bit of code will make this clearer.  The request looks like this:
コードを見たほうが話が早いだろう。まずリクエストはこのようになる。

\begin{verbatim}
connection[CONNECTION_INTERFACE_CONTACTS].GetContactAttributes(
  [ 1, 2, 3 ], # contact handles
  [ "ofdT.Connection.Interface.Aliasing",
    "ofdT.Connection.Interface.Avatars",
    "ofdT.Connection.Interface.ContactGroups",
    "ofdT.Connection.Interface.Location"
  ],
  False # don't hold a reference to these contacts
)
\end{verbatim}

%% \noindent and the reply might look like this:
\noindent
そしてその応答はこのようになる。

\begin{verbatim}
{ 1: { 'ofdT.Connection.Interface.Aliasing/alias': 'Harvey Cat',
       'ofdT.Connection.Interface.Avatars/token': hex string,
       'ofdT.Connection.Interface.Location/location': location,
       'ofdT.Connection.Interface.ContactGroups/groups': [ 'Squid House' ],
       'ofdT.Connection/contact-id': 'harvey@nom.cat'
     },
  2: { 'ofdT.Connection.Interface.Aliasing/alias': 'Escher Cat',
       'ofdT.Connection.Interface.Avatars/token': hex string,
       'ofdT.Connection.Interface.Location/location': location,
       'ofdT.Connection.Interface.ContactGroups/groups': [],
       'ofdT.Connection/contact-id': 'escher@tuxedo.cat'
     },
  3: { 'ofdT.Connection.Interface.Aliasing/alias': 'Cami Cat',
        ...
     }
}
\end{verbatim}

\end{aosasect2}

\end{aosasect1}

%% \begin{aosasect1}{Connections, Channels and Clients}
\begin{aosasect1}{コネクション、チャネル、そしてクライアント}
\label{sec.telepathy.ccc}

%% \begin{aosasect2}{Connections}
\begin{aosasect2}{コネクション}

%% A Connection is created by the Connection Manager to establish a
%% connection to a single protocol/account. For example, connecting to
%% the XMPP accounts \code{escher@tuxedo.cat} and \code{cami@egg.cat}
%% would result in two Connections, each represented by a D-Bus
%% object. Connections are typically set up by the Account Manager, for
%% the currently enabled accounts.
コネクションを作るのはConnection Managerで、単一のプロトコル／アカウントとの接続を確立する。
たとえばXMPPアカウント\code{escher@tuxedo.cat}および\code{cami@egg.cat}
と接続すると二つのコネクションが作られることになり、それぞれがD-Busオブジェクトとして表される。
コネクションの準備をするのはたいていの場合Account Managerで、
現在有効なアカウントに対して行う。

%% The Connection provides some mandatory functionality for managing and
%% monitoring the connection status and for requesting channels. It can
%% then also provide a number of optional features, depending on the
%% features of the protocol. These are provided as optional D-Bus
%% interfaces (as discussed in the previous section) and listed by the
%% Connection's \code{Interfaces} property.
コネクションは、いくつかの必須機能を提供する。
接続状態の管理や監視、そしてチャネルのリクエストに欠かせないものである。
そしてまた、オプションの機能も提供する。
どんな機能を提供するかは、そのプロトコルの機能に依存する。
これらはオプションのD-Busインターフェイス(先ほど説明したもの)
として提供され、コネクションの\code{Interfaces}プロパティで一覧できる。

%% Typically Connections are managed by the Account Manager, created
%% using the properties of the respective accounts. The Account Manager
%% will also synchronize the user's presence for each account to its
%% respective connection and can be asked to provide the connection path
%% for a given account.
通常は、コネクションを管理するのはAccount Managerで、
対応するアカウントのプロパティを使って作成する。
Account Managerは各アカウントに対してユーザーの存在を
それに対応する接続と同期させ、指定したアカウント用のコネクションパスを答えることができる。

\end{aosasect2}

%% \begin{aosasect2}{Channels}
\begin{aosasect2}{チャネル}

%% Channels are the mechanism through which communications are carried
%% out.  A channel is typically an IM conversation, voice or video call
%% or file transfer, but channels are also used to provide some stateful
%% communication with the server itself, (e.g., to search for chat rooms
%% or contacts). Each channel is represented by a D-Bus object.
チャネルは、実際の通信を行う仕組みである。
通常はIMの会話だったり音声や映像での通話だったりファイル転送だったりするが、
チャネルを使ってサーバー自身とのステートフルな通信(チャットルームや連絡先の検索など)をさせることもできる。
個々のチャネルはD-Busオブジェクトとして表される。

%% Channels are typically between two or more users, one of whom is
%% yourself. They typically have a target identifier, which is either
%% another contact, in the case of one-to-one communication; or a room
%% identifier, in the case of multi-user communication (e.g., a chat
%% room). Multi-user channels expose the \code{Group} interface, which
%% lets you track the contacts who are currently in the channel.
チャネルは一般に複数のユーザーの間でできるものであり、その中の一人があなたとなる。
通常は、ターゲットIDを持っている。これは、一対一の通信の場合は通信の相手を指し、
マルチユーザーの通信(チャットルームなど)の場合はルームIDを指す。
マルチユーザーのチャネルは\code{Group}インテーフェイスを公開しており、
これを使えば現在チャネルに参加している連絡先を追える。

%% Channels belong to a Connection, and are requested from the Connection
%% Manager, usually via the Channel Dispatcher; or they are created by
%% the Connection in response to a network event (e.g., incoming chat),
%% and handed to the Channel Dispatcher for dispatching.
チャネルはコネクションに属し、Connection Managerからのリクエストを(通常はChannel Dispatcher経由で)
受ける。あるいは、ネットワーク上でのイベント(チャットの受信など)に対応してコネクションがチャネルを作ることもある。
そしてそれをChannel Dispatcherに渡してディスパッチさせる。

%% The type of channel is defined by the channel's \code{ChannelType}
%% property. The core features, methods, properties, and signals that are
%% needed for this channel type (e.g., sending and receiving text
%% messages) are defined in the appropriate \code{Channel.Type} D-Bus
%% interface, for instance \code{Channel.Type.Text}. Some channel types
%% may implement optional additional features (e.g., encryption) which
%% appear as additional interfaces listed by the channel's
%% \code{Interfaces} property.  An example text channel that connects the
%% user to a multi-user chatroom might have the interfaces shown in
%% \aosatblref{tbl.telepathy.textchannel}.
チャネルの型を定義するのが、チャネルの\code{ChannelType}プロパティである。
このチャネルの型で必要となるフィーチャ(テキストメッセージの送受信など)やメソッド、プロパティ、シグナルの定義は
適切な\code{Channel.Type} D-Busインターフェイスで行われる。\code{Channel.Type.Text}などである。
チャネルの型によっては、オプションで追加機能(暗号化など)を実装しているものもある。
これらは別のインターフェイスとして、チャネルの\code{Interfaces}プロパティから得られる。
あるユーザーをマルチユーザーのチャットルームに接続させるテキストチャネルを例にして考えよう。
そのインターフェイスは\aosatblref{tbl.telepathy.textchannel}に示すようなものとなる。

\begin{table}[h]\centering
  \begin{tabular}{ |lp{3.0in}| }
   \hline
    %% \code{odfT.Channel} & Features common to all channels \\
    %% \code{odfT.Channel.Type.Text} & The Channel Type, includes features common to text channels \\
    %% \code{odfT.Channel.Interface.Messages} & Rich-text messaging \\
    %% \code{odfT.Channel.Interface.Group} & List, track, invite and approve members in this channel \\
    %% \code{odfT.Channel.Interface.Room} & Read and set properties such as the chatroom's subject \\
    \code{odfT.Channel} & すべてのチャネルに共通するフィーチャ \\
    \code{odfT.Channel.Type.Text} & チャネルの型。テキストチャネルに共通するフィーチャも含む \\
    \code{odfT.Channel.Interface.Messages} & リッチテキストメッセージング \\
    \code{odfT.Channel.Interface.Group} & このチャネルのメンバーの一覧、追跡、招待、そして承認 \\
    \code{odfT.Channel.Interface.Room} & チャットルームの件名などのプロパティの読み込みと設定 \\
   \hline
  \end{tabular}
  %% \caption{Example Text Channel}
  \caption{テキストチャネルの例}
  \label{tbl.telepathy.textchannel}
\end{table}

%% \begin{aosabox}{Contact List Channels: A Mistake}
\begin{aosabox}{コンタクトリストチャネル: 失敗例}

%% In the first versions of the Telepathy specification, contact lists
%% were considered a type of channel. There were several server-defined
%% contact lists (subscribed users, publish-to users, blocked users),
%% that could be requested from each Connection. The members of the list
%% were then discovered using the \code{Group} interface, like for a
%% multi-user chat.
最初のバージョンのTelepathyの仕様では、連絡先リストもチャネルの一種だとしていた。
サーバー側で定義された連絡先リスト(購読ユーザー一覧、配信先ユーザー一覧、ブロック済みユーザー一覧など)
があって、これをコネクションからリクエストできた。
リストのメンバーを取得するには\code{Group}インターフェイスを使う。
ちょうどマルチユーザーのチャットと同じような仕組みだ。

%% Originally this would allow for channel creation to occur only once
%% the contact list had been retrieved, which takes time on some
%% protocols. A client could request the channel whenever it liked, and
%% it would be delivered once ready, but for users with lots of contacts
%% this meant the request would occasionally time out.  Determining the
%% subscription/publish/blocked status of a client required checking
%% three channels.
当初は、チャネルを作るのは連絡先リストを取得するときの一度だけでよかったが、
プロトコルによってはこれは時間のかかる処理だった。
クライアント側からはいつでもチャネルをリクエストでき、準備ができしだいすぐに配送されたが、
多数の連絡先を持つユーザーの場合は、時にリクエストがタイムアウトすることもあった。
あるクライアントの購読/配信/ブロックの状態を知るには、三つのチャネルをチェックしなければいけなかったのだ。

%% Contact Groups (e.g., Friends) were also exposed as channels, one
%% channel per group. This proved extremely difficult for client
%% developers to work with.  Operations like getting the list of groups a
%% contact was in required a significant amount of code in the client.
%% Further, with the information only available via channels, properties
%% such as a contact's groups or subscription state could not be
%% published via the Contacts interface.
連絡先グループ(友人など)もチャネルとして公開され、グループごとにひとつのチャネルになっていた。
クライアント側の開発者にしてみると、これは非常に使いづらいものであることがわかった。
たとえば、グループの一覧を取得しようとすれば、クライアント側で大量のコードを書く必要があったのだ。
さらに、情報がチャネル経由でしか得られないので、ある連絡先のグループや購読の状態を
Contactsインターフェイス経由で公開できないことになる。

%% Both channel types have since been replaced by interfaces on the
%% Connection itself which expose contact roster information in ways more
%% useful to client authors, including subscription state of a contact
%% (an enum), groups a contact is in, and contacts in a group.  A signal
%% indicates when the contact list has been prepared.
そのため、どちらのチャネル型についても結局はコネクション自身のインターフェイスに
置き換えた。こうすることで、連絡先情報や各連絡先の購読状況、所属グループ、グループのメンバーなどを
より有用な形式でクライアント側に公開できるようになった。
連絡先リストの準備ができたら、シグナルで通知する。

\end{aosabox}

\end{aosasect2}

%% \begin{aosasect2}{Requesting Channels, Channel Properties and Dispatching}
\begin{aosasect2}{チャネルのリクエスト、チャネルのプロパティそしてディスパッチ}

%% Channels are requested using a map of properties you wish the desired
%% channel to possess. Typically, the channel request will include the
%% channel type, target handle type (contact or room) and target.
%% However, a channel request may also include properties such as the
%% filename and filesize for file transfers, whether to initially include
%% audio and video for calls, what existing channels to combine into a
%% conference call, or which contact server to conduct a contact search
%% on.
チャネルをリクエストするときには、そのチャネルに持たせたいプロパティのマップを使う。
一般に、チャネルのリクエストに含まれるのはチャネルの型とターゲットのハンドル型(連絡先あるいはルーム)そしてターゲットだ。
しかし、チャネルのリクエストにはそれ以外のプロパティも含めることもできる。ファイル転送なら
ファイル名とファイルサイズ、通話なら音声と映像のどちらを使うか、どの既存のチャネルをカンファレンスコールに含めるか、
どのコンタクトサーバーから連絡先を探すか、などがその一例だ。

%% The properties in the channel request are properties defined by
%% interfaces of the Telepathy spec, such as the \code{ChannelType}
%% property (\aosatblref{tbl.telepathy.channelrequest}). They are
%% qualified with the namespace of the interface they come from
%% Properties which can be included in channel requests are marked as
%% \emph{requestable} in the Telepathy spec.
チャネルリクエストに含まれるプロパティは、Telepathyの仕様に定められたインターフェイスで定義されているものとなる。
たとえば\code{ChannelType}プロパティ(\aosatblref{tbl.telepathy.channelrequest})がそのひとつである。
プロパティは、その定義元のインターフェイスの名前空間で表す。
チャネルリクエストに含めることのできるプロパティは、Telepathyの仕様上では
\emph{requestable}と記されている。

\begin{table}[h]\centering
  \begin{tabular}{ |ll| }
    \hline
    %% Property & Value \\
    プロパティ & 値 \\
    \hline
    \code{ofdT.Channel.ChannelType} & \code{ofdT.Channel.Type.Text} \\
    \code{ofdT.Channel.TargetHandleType} & \code{Handle\_Type\_Contact} (1) \\
    \code{ofdT.Channel.TargetID} & \code{escher@tuxedo.cat} \\
    \hline
  \end{tabular}
  %% \caption{Example Channel Requests}
  \caption{チャネルリクエストの例}
  \label{tbl.telepathy.channelrequest}
\end{table}

%% The more complicated example in \aosatblref{tbl.telepathy.transfer}
%% requests a file transfer channel. Notice how the requested properties
%% are qualified by the interface from which they come.  (For brevity,
%% not all required properties are shown.)
もう少し複雑な例を\aosatblref{tbl.telepathy.transfer}に示す。これはファイル転送チャネルへのリクエストだ。
リクエストしているプロパティが、その定義元のインターフェイス名で指定されているところに注目しよう
(簡潔にするために、必須プロパティの一部を省略した)。

\begin{table}[h]\centering
\begin{tabular}{ |ll| }
    \hline
    %% Property & Value \\
    プロパティ & 値 \\
    \hline
    \code{ofdT.Channel.ChannelType} & \code{ofdT.Channel.Type.FileTransfer} \\
    \code{ofdT.Channel.TargetHandleType} & \code{Handle\_Type\_Contact} (1) \\
    \code{ofdT.Channel.TargetID} & \code{escher@tuxedo.cat} \\
    \code{ofdT.Channel.Type.FileTransfer.Filename} & \code{meow.jpg} \\
    \code{ofdT.Channel.Type.FileTransfer.ContentType} & \code{image/jpeg} \\
    \hline
  \end{tabular}
  %% \caption{File Transfer Channel Request}
  \caption{ファイル転送チャネルのリクエスト}
  \label{tbl.telepathy.transfer}
\end{table}

%% Channels can either be \emph{created} or \emph{ensured}. Ensuring a
%% channel means creating it only if it does not already exist. Asking to
%% create a channel will either result in a completely new and separate
%% channel being created, or in an error being generated if multiple
%% copies of such a channel cannot exist. Typically you wish to ensure
%% text channels and calls (i.e., you only need one conversation open with
%% a person, and in fact many protocols do not support multiple separate
%% conversations with the same contact), and wish to create file
%% transfers and stateful channels.
チャネルは、\emph{作成(create)する}か、あるいは\emph{確保(ensure)する}ことができる。
チャネルを確保するとは、そのチャネルがまだ存在しないときにだけ作成するということである。
チャネルを作成しようとした場合は、まったく新しい個別のチャネルを作成する。
ただし、すでにそのチャネルが存在する場合にはエラーになる。同じチャネルのコピーは複数存在できないからである。
一般的には、テキストチャネルや通話に関しては「確保」を使い
(だれかとのやりとりに必要なチャネルはひとつだけだし、
実際のところ、たいていのプロトコルは同じ相手と複数の会話を別々にできるようになっていない)
、ファイル転送やステートフルなチャネルなどでは「作成」を使うことになるだろう。

%% Newly created channels (requested or otherwise) are announced by a
%% signal from the Connection. This signal includes a map of the
%% channel's \emph{immutable} properties. These are the properties which
%% are guaranteed not to change throughout the channel's lifetime.
%% Properties which are considered immutable are marked as such in the
%% Telepathy spec, but typically include the channel's type, target
%% handle type, target, initiator (who created the channel) and
%% interfaces.  Properties such as the channel's state are obviously not
%% included.
(リクエストなり何なりによって)新たに作成されたチャネルは、コネクションからのシグナルで通知される。
このシグナルには、チャネルの\emph{不変}なプロパティのマップが含まれる。
不変なプロパティとは、そのチャネルの活動期間を通して値が変わらないことが保証されているプロパティのことだ。
不変であろうとみなされているプロパティについてはTelepathyの仕様でそのように明記されているが、
一般的にはチャネルの型やターゲット、作成者、インターフェイスなどがそれに含まれる。
チャネルの状態などのプロパティは、もちろん不変ではない。

%% \begin{aosabox}{Old-School Channel Requesting}
\begin{aosabox}{昔ながらのチャネルリクエスト}

%% Channels were originally requested simply by type, handle type and
%% target handle.  This wasn't sufficiently flexible because not all
%% channels have a target (e.g., contact search channels), and some
%% channels require additional information included in the initial
%% channel request (e.g., file transfers, requesting voicemails and
%% channels for sending SMSes).
チャネルのリクエストは元々はシンプルなもので、単に型とハンドルタイプそしてターゲットハンドルを指定するだけのことだった。
しかしこれは柔軟性に欠けていた。というのも、すべてのチャネルがターゲットを持っているわけではないし
(例: 連絡先検索チャネル)、最初のリクエストのときにそれ以外の情報を必要とするチャネルもあったからだ
(例: ファイル転送、ボイスメールのリクエスト、SMS送信用のチャネル)。

%% It was also discovered that two different behaviors might be desired
%% when a channel was requested (either to create a guaranteed unique
%% channel, or simply ensure a channel existed), and until this time the
%% Connection had been responsible for deciding which behavior would
%% occur.  Hence, the old method was replaced by the newer, more
%% flexible, more explicit ones.
また、チャネルをリクエストするときには二通りの振る舞い
(一意なチャネルを新たに作成するのか単に既存のチャネルを確保するだけなのか)
を考えないといけないこともわかったし、当時はどっちの振る舞いにするのかを決めるのが
コネクションの役割だった。そんなこともあって、かつての方式はとりやめて
新しい方式に変わったのだ。こちらのほうがより柔軟で明示的な方式である。

\end{aosabox}

\pagebreak

%% Returning a channel's immutable properties when you create or ensure
%% the channel makes it much faster to create a proxy object for the
%% channel. This is information we now don't have to request.  The map in
%% \aosatblref{tbl.telepathy.immutable} shows the immutable properties
%% that might be included when we request a text channel (i.e., using the
%% channel request in \aosatblref{tbl.telepathy.transfer}). Some
%% properties (including \code{TargetHandle} and \code{InitiatorHandle})
%% have been excluded for brevity.
チャネルを作成あるいは確保するときにそのチャネルの不変なプロパティを返すようにしたことで、
そのチャネルのプロキシーオブジェクトを高速に作れるようになった。
必要な情報をわざわざリクエストする必要がなくなったのだ。
\aosatblref{tbl.telepathy.immutable}は不変なプロパティを示すもので、
テキストチャネルをリクエストした
(つまり、\aosatblref{tbl.telepathy.transfer}のチャネルリクエストを使った)
場合の一例だ。\code{TargetHandle}や\code{InitiatorHandle}など
一部のプロパティは、簡潔にまとめるために省略した。

\begin{table}[h]\centering
\begin{tabular}{ |p{6cm} p{6cm} | }
    \hline
    %% Property & Value \\
    プロパティ & 値 \\
    \hline
    \code{ofdT.Channel.ChannelType} & \code{Channel.Type.Text} \\
    \code{ofdT.Channel.Interfaces} & \code{{[} Channel.Interface.Messages,\newline Channel.Interface.Destroyable,\newline Channel.Interface.ChatState {]}}  \\
    \code{ofdT.Channel.TargetHandleType} & \code{Handle\_Type\_Contact} (1) \\
    \code{ofdT.Channel.TargetID} & \code{escher@tuxedo.cat} \\
    \code{ofdT.Channel.InitiatorID} & \code{danielle.madeley@collabora.co.uk} \\
    \code{ofdT.Channel.Requested} & \code{True} \\
    \code{ofdT.Channel.Interface.Messages.}{\newline}\hspace*{1em}\code{SupportedContentTypes} & \code{{[} text/html, text/plain {]}} \\
    \hline
  \end{tabular}
  %% \caption{Example Immutable Properties Returned by a New Channel}
  \caption{新しいチャネルが返す不変なプロパティの例}
  \label{tbl.telepathy.immutable}
\end{table}

%% The requesting program typically makes a request for a channel to the
%% Channel Dispatcher, providing the account the request is for, the
%% channel request, and optionally the name of a the desired handler
%% (useful if the program wishes to handle the channel itself).  Passing
%% the name of an account instead of a connection means that the Channel
%% Dispatcher can ask the Account Manager to bring an account online if
%% required.
リクエストする側のプログラムは、あるチャネルへのリクエストを通常は
Channel Dispatcherに対して送る。このときに渡すのは、
そのリクエストの対象となるアカウントとチャネルリクエストであり、
必要なハンドラをオプションで渡すこともある
(これは、プログラム側でチャネル自身を扱いたい場合に便利だ)。
コネクションではなくアカウントの名前を渡す意味は、
Channel DispatcherからAccount Managerに対して、
必要に応じてそのアカウントをオンラインにするよう依頼できるようにすることだ。

%% Once the request is complete, the Channel Dispatcher will either pass
%% the channel to the named Handler, or locate an appropriate Handler
%% (see below for discussion on Handlers and other clients). Making the
%% name of the desired Handler optional makes it possible for programs
%% that have no interest in communication channels beyond the initial
%% request to request channels and have them handled by the best program
%% available (e.g., launching a text chat from your email client).
リクエストが完了すると、Channel Dispatcherがそのチャネルを名前付きのハンドラに渡すか
適切なハンドラの場所を示す(ハンドラやその他のクライアントに関しては後述する)。
要求するハンドラの名前をオプションにすることで、
最初のリクエスト以降の通信チャネルに興味のないプログラムでも
チャネルをリクエストできるようになり、最適なプログラムで処理させるようにできる
(メールソフトからテキストチャットを立ち上げるなど)。

%% \aosafigure[300pt]{../images/telepathy/dispatching-model.eps}{Channel Request and Dispatching}{fig.telepathy.request}
\aosafigure[300pt]{../images/telepathy/dispatching-model.eps}{チャネルリクエストとディスパッチ}{fig.telepathy.request}

%% The requesting program makes a channel request to the Channel
%% Dispatcher, which in turn forwards the request to the appropriate
%% Connection. The Connection emits the NewChannels signal which is
%% picked up by the Channel Dispatcher, which then finds the appropriate
%% client to handle the channel.  Incoming, unrequested channels are
%% dispatched in much the same way, with a signal from the Connection
%% that is picked up by the Channel Dispatcher, but obviously without the
%% initial request from a program.
リクエストする側のプログラムはチャネルリクエストをChannel Dispatcher
に送り、Channel Dispatcherはそのリクエストを適切なコネクションに転送する。
コネクションはNewChannelsシグナルを発行し、これをChannel Dispatcher
が受け取ると、そのチャネルを処理できる適切なクライアントを探す。
リクエストしたものでない、外部から受信したチャネルのディスパッチも同様に行い、
コネクションからのシグナルをChannel Dispatcherが取り上げる。
しかし当然、プログラムからの最初のリクエストはない。

\end{aosasect2}

%% \begin{aosasect2}{Clients}
\begin{aosasect2}{クライアント}

%% Clients handle or observe incoming and outgoing communications
%% channels. A client is anything that is registered with the Channel
%% Dispatcher.  There are three types of clients (though a single client
%% may be two, or all three, types if the developer wishes):
クライアントは、送受信チャネルを処理したり監視したりする。
クライアントとは、Channel Dispatcherで登録したもののことである。
クライアントには次の三種類の形式がある(開発者次第で、
あるひとつのクライアントが二種類の形式あるいは三種類すべての形式を兼ねることもある)。

\begin{aosadescription}

  %% \item{Observers}: Observe channels without interacting with
  %%   them. Observers tend to be used for chat and activity logging
  %%   (e.g., incoming and outgoing VoIP calls).
  \item{オブザーバー}: チャネルとのやりとりをせずにただ観察する。
  オブザーバーは、チャットに使ったりアクティビティ(VoIP通話の発信や着信など)の記録
  に使ったりすることが多い。

  %% \item{Approvers}: Responsible for giving users an opportunity to
  %%   accept or reject an incoming channel.
  \item{アプルーバー}: チャネルの受信を許可するか拒否するかをユーザーが決められるようにする。

  %% \item{Handlers}: Actually interact with the channel. That might be
  %%   acknowledging and sending text messages, sending or receiving a
  %%   file, etc. A Handler tends to be associated with a user interface.
  \item{ハンドラー}: 実際にチャネルとのやりとりをする。
  テキストメッセージを受け入れたり送信したり、ファイルを送受信したりといったものである。
  ハンドラーは、ユーザーインターフェイスと関連づけられることが多い。

\end{aosadescription}

%% Clients offer D-Bus services with up to three interfaces:
%% \code{Client.Observer}, \code{Client.Approver}, and
%% \code{Client.Handler}. Each interface provides a method that the
%% Channel Dispatcher can call to inform the client about a channel to
%% observe, approve or handle.
クライアントは、最大で三つまでのインターフェイスを持つD-Busサービスを提供する。
\code{Client.Observer}、\code{Client.Approver}そして\code{Client.Handler}だ。
それぞれのインターフェイスが提供するメソッドをChannel Dispatcherが呼んで、
観察あるいは許可あるいは処理させたいチャネルをクライアントに伝える。

%% The Channel Dispatcher dispatches the channel to each group of clients
%% in turn. First, the channel is dispatched to all appropriate
%% Observers.  Once they have all returned, the channel is dispatched to
%% all the appropriate Approvers. Once the first Approver has approved or
%% rejected the channel, all other Approvers are informed and the channel
%% is finally dispatched to the Handler.  Channel dispatching is done in
%% stages because Observers might need time to get set up before the
%% Handler begins altering the channel.
Channel Dispatcherは、そのチャネルを各クライアントグループに振り分ける。
まず、そのチャネルを適切なオブザーバーすべてにディスパッチする。
すべての結果が戻ってきたら、チャネルを適切なアプルーバーすべてにディスパッチする。
最初のアプルーバーがチャネルを許可あるいは拒否すると、その他すべてのアプルーバーにそれが通知され、
最終的にチャネルはハンドラーに渡される。チャネルのディスパッチがこのように段階を踏んで行われる理由は、
オブザーバーの準備をするのにある程度の時間が必要で、それまではハンドラーがチャネルに手を加えられないからである。

%% Clients expose a channel filter property which is a list of filters
%% read by the Channel Dispatcher so that it knows what sorts of channels
%% a client is interested in. A filter must include at least the channel
%% type, and target handle type (e.g., contact or room) that the client
%% is interested in, but it can contain more properties. Matching is done
%% against the channel's immutable properties, using simple equality for
%% comparison.  The filter in \aosatblref{tbl.telepathy.filter} matches
%% all one-to-one text channels.
クライアントはチャネルフィルタプロパティを公開する。これはChannel Dispatcher
が読むフィルタの一覧で、これを読めばそのクライアントがどんなチャネルに興味を持っているのかがわかる。
フィルタに少なくとも含める必要があるのは、チャネル型とそのクライアントが扱えるターゲットハンドル型
(連絡先あるいはルームなど)である。それ以外にもプロパティを含めることができる。
このフィルタをチャネルの不変プロパティとマッチングさせる。マッチするかどうかは、単純に一致するかどうかで判断する。
たとえば\aosatblref{tbl.telepathy.filter}のフィルタは、すべての一対一テキストチャネルにマッチする。

\begin{table}\centering
\begin{tabular}{ |ll| }
  \hline
    %% Property & Value \\
    プロパティ & 値 \\
  \hline
    \code{ofdT.Channel.ChannelType} & \code{Channel.Type.Text} \\
    \code{ofdT.Channel.TargetHandleType} & \code{Handle\_Type\_Contact} (1) \\
  \hline
  \end{tabular}
  %% \caption{Example Channel Filter}
  \caption{チャネルフィルタの例}
  \label{tbl.telepathy.filter}
\end{table}

%% Clients are discoverable via D-Bus because they publish services
%% beginning with the well-known name \code{ofdT.Client} (for example
%% \code{ofdT.Client.Empathy.Chat}).  They can also optionally install a
%% file which the Channel Dispatcher will read specifying the channel
%% filters. This allows the Channel Dispatcher to start a client if it is
%% not already running.  Having clients be discoverable in this way makes
%% the choice of user interface configurable and changeable at any time
%% without having to replace any other part of Telepathy.
クライアントをD-Bus経由で発見できるのは、クライアントが既知の名前\code{ofdT.Client}
から始まる(たとえば\code{ofdT.Client.Empathy.Chat})サービスを公開しているからである。
また、オプションでファイルをインストールできる。これをChannel Dispatcherが読んで、
チャネルフィルタを指定する。これを使えば、Channel Dispatcher
からまだ起動していないクライアントを立ち上げることができる。
このようにしてクライアントを発見可能にしておくことで、ユーザーインターフェイスを
設定や変更がいつでもできるようになり、その時にTelepathyの他の部分に一切手を加える必要がなくなる。

%% \begin{aosabox}{All or Nothing}
\begin{aosabox}{オールオアナッシング}

%% It is possible to provide a filter indicating you are interested in
%% all channels, but in practice this is only useful as an example of
%% observing channels. Real clients contain code that is specific to
%% channel types.
すべてのチャネルを扱えるというフィルタを提供することもできる。
しかし、現実的に考えると、そんなことをして有用なのはチャネルを観察するサンプルくらいである。
実際のクライアントは、チャネル型に固有のコードを含むものだ。

%% An empty filter indicates a Handler is not interested in any channel
%% types. However it is still possible to dispatch a channel to this
%% handler if you do so by name.  Temporary Handlers which are created on
%% demand to handle a specific channel use such a filter.
空のフィルタを渡すと、そのハンドラーは一切のチャネル型に興味を持たないということになる。
しかしそれでも、名前を直接指定してそのハンドラに処理をディスパッチできる。
特定のチャネルを処理するためだけに一時的に作るハンドラーなどで、このようなフィルタを使うことがある。

\end{aosabox}

\end{aosasect2}

\end{aosasect1}

%% \begin{aosasect1}{The Role of Language Bindings}
\begin{aosasect1}{言語バインディングの役割}

%% As Telepathy is a D-Bus API, and thus can driven by any programming
%% language that supports D-Bus.  Language bindings are not required for
%% Telepathy, but they can be used to provide a convenient way to use it.
TelepathyはD-Bus APIなので、D-Busをサポートするあらゆる言語から使うことができる。
言語バインディングはTelepathyに必須のものではないが、これを使えばTelepathyを
さらに便利に活用できる。

%% Language bindings can be split into two groups: low-level bindings
%% that include code generated from the specification, constants, method
%% names, etc.; and high-level bindings, which are hand-written code that
%% makes it easier for programmers to do things using Telepathy.
%% Examples of high-level bindings are the GLib and Qt4 bindings.
%% Examples of low-level bindings are the Python bindings and the
%% original libtelepathy C bindings, though the GLib and Qt4 bindings
%% include a low-level binding.
言語バインディングは二つのグループに分類できる。ローレベルのバインディングとハイレベルのバインディングだ。
ローレベルのバインディングには、仕様や定数、メソッド名に基づいて生成したコードが含まれる。
ハイレベルのバインディングは手書きのコードで、プログラマーがTelepathyをより使いやすくするものだ。
ハイレベルのバインディングの例にはGLibやQt4用のバインディングがある。
ローレベルのバインディングの例はPythonバインディングや
Cのlibtelepathyであるが、GLibやQt4バインディングにもローレベルのバインディングが含まれている。

%% \begin{aosasect2}{Asynchronous Programming}
\begin{aosasect2}{非同期プログラミング}

%% Within the language bindings, all method calls that make requests over
%% D-Bus are asynchronous: the request is made, and the reply is given in
%% a callback. This is required because D-Bus itself is asynchronous.
言語バインディング内でのすべてのメソッド呼び出しはD-Bus越しのリクエストであり、
これは非同期になる。リクエストを投げて、結果はコールバックで取得するという方式だ。
D-Bus自体が非同期なため、これが必須となる。

%% Like most network and user interface programming, D-Bus requires the
%% use of an event loop to dispatch callbacks for incoming signals and
%% method returns. D-Bus integrates well with the GLib mainloop used by
%% the GTK+ and Qt toolkits.
ネットワークやユーザーインターフェイスがからむプログラミングにはよくあることだが、
D-Busではイベントループを使う必要がある。
入力シグナル用のコールバックへのディスパッチやメソッドの結果を返すときにこれを使う。
D-Busは、GTK+やQtが使うGLibメインループとうまく統合されている。

%% Some D-Bus language bindings (such as dbus-glib) provide a
%% pseudo-synchronous API, where the main loop is blocked until the
%% method reply is returned.  Once upon a time this was exposed via the
%% telepathy-glib API bindings. Unfortunately using pseudo-synchronous
%% API turns out to be fraught with problems, and was eventually removed
%% from telepathy-glib.
D-Bus言語バインディングの中には、dbus-glibのように疑似同期型API
を提供するものもある。このAPIでは、メインループをブロックしてメソッドの結果を待つ。
昔々は、これはtelepathy-glib APIバインディング経由で公開されていた。
残念ながら、疑似同期型のAPIを使っているといろんな問題に悩まされることになり、
最終的にtelepathy-glibから削除された。

%% \begin{aosabox}{Why Pseudo-Synchronous D-Bus Calls Don't Work}
\begin{aosabox}{疑似同期D-Bus呼び出しが失敗する理由}

%% The pseudo-synchronous interface offered by dbus-glib and other D-Bus
%% bindings is implemented using a request-and-block technique. While
%% blocking, only the D-Bus socket is polled for new I/O and any D-Bus
%% messages that are not the response to the request are queued for later
%% processing.
dbus-glibなどのD-Busバインディングが提供する疑似同期インターフェイスの実装は、
request-and-block方式になっている。ブロックしている間、
D-Busソケットだけが新たなI/Oをポールする。
リクエストへの応答以外のD-Busメッセージはすべてキューに入れておき、後で処理する。

%% This causes several major and inescapable problems:
それが原因で、重大かつ不可避な問題がいくつか発生する。

\begin{aosaitemize}

  %% \item The caller is blocked while waiting for the request to be
  %%   answered.  It (and its user interface, if any) will be completely
  %%   unresponsive. If the request requires accessing the network, that
  %%   takes time; if the callee has locked up, the caller will be
  %%   unresponsive until the call times out.
  \item 呼び出し元はブロックされ、リクエストに対する応答があるまで待たされる。
  呼び出し元(そしてそれに対応するユーザーインターフェイス)は、その間は何もできなくなる。
  ネットワーク越しのリクエストの場合などは、それなりに時間がかかる。
  呼び出された側がダウンした場合などは、タイムアウトになるまで呼び出し元は身動きできなくなる。

    %% Threading is not a solution here because threading is just another
    %% way of making your calling asynchronous. Instead you may as well
    %% make asynchronous calls where the responses come in via the
    %% existing event loop.
    スレッドを分けたって問題は解決しない。スレッドを分けるということは、
    単に非同期呼び出しを別の方法で行っているだけだからである。
    それだったら普通に非同期呼び出しをしたほうがいい。そうすれば、レスポンスは
    既存のイベントループ経由で得られる。

  %% \item Messages may be reordered. Any messages received before the
  %%   watched-for reply will be placed on a queue and delivered to the
  %%   client after the reply.
  \item メッセージの順番が入れ替わることがあり得る。
  応答待ちのメッセージの前に受け取ったメッセージはキューに入るので、
  その応答がクライアントに配送されるのは応答待ちメッセージの処理を終えた後になる。

    %% This causes problems in situations where a signal indicating a
    %% change of state (i.e., the object has been destroyed) is now
    %% received after the method call on that object fails (i.e., with
    %% the exception \code{UnknownMethod}).  In this situation, it is
    %% hard to know what error to display to the user.  Whereas if we
    %% receive a signal first, we can cancel pending D-Bus method calls,
    %% or ignore their responses.
    これが問題になるのは、状態が変わった(オブジェクトが破棄されたなど)というシグナルを受信する前に
    そのオブジェクトのメソッド呼び出しを実行してしまう(その結果として\code{UnknownMethod}が発生する)などの場合だ。
    こんなときは、ユーザーにどんなエラーメッセージを見せればいいのかわからなくなる。
    もし事前にシグナルを受け取っていたら、ペンディング中のD-Busメソッド呼び出しをキャンセルするなり
    その応答を無視するなりの対策ができる。

  %% \item Two processes making pseudo-blocking calls on each other can
  %%   deadlock, with each waiting for the other to respond to its query.
  %%   This scenario can occur with processes that are both a D-Bus
  %%   service and call other D-Bus services (for example, Telepathy
  %%   clients). The Channel Dispatcher calls methods on clients to
  %%   dispatch channels, but clients also call methods on the Channel
  %%   Dispatcher to request the opening of new channels (or equally they
  %%   call the Account Manager, which is part of the same process).
  \item 二つのプロセスがお互いに疑似同期呼び出しをするとデッドロックが発生し、
  お互いが相手への問い合わせの応答を待ち続ける状態になってしまう。
  こんな状況が発生するのは、あるD-Busサービスが別のD-Busサービス(Telepathyクライアントなど)を呼ぶ場合などである。
  Channel Dispatcherはクライアントのメソッドを呼んでチャネルをディスパッチする。
  一方でクライアントもChannel Dispatcherのメソッドを呼んで新たなチャネルのオープンを要求する
  (あるいはAccount Managerを呼ぶこともあって、こちらの場合も同様の可能性がある)。

\end{aosaitemize}
\end{aosabox}

%% Method calls in the first Telepathy bindings, generated in C, simply
%% used typedef callback functions. Your callback function simply had to
%% implement the same type signature.
最初のTelepathyバインディングはCで生成したものだったが、そこでのメソッド呼び出しは
単にtypedefコールバック関数を使っていた。コールバック関数側では
単にそれと同じ型シグネチャを実装しておく必要があるだけだった。

\begin{verbatim}
typedef void (*tp_conn_get_self_handle_reply) (
    DBusGProxy *proxy,
    guint handle,
    GError *error,
    gpointer userdata
);
\end{verbatim}

%% \noindent This idea is simple, and works for C, so was continued into
%% the next generation of bindings.
\noindent
このアイデアはシンプルだしCでも動くので、次世代のバインディングにも引き継がれた。

%% In recent years, people have developed a way to use scripting
%% languages such as Javascript and Python, as well as a C\#-like
%% language called Vala, that use GLib/GObject-based APIs via a tool
%% called GObject-Introspection.  Unfortunately, it's extremely difficult
%% to rebind these types of callbacks into other languages, so newer
%% bindings are designed to take advantage of the asynchronous callback
%% features provided by the languages and GLib.
最近は、JavaScriptやPythonのようなスクリプティング言語、そしてValaというC風の言語を使おうとする人も出てきた。
これらはGLib/GObjectベースのAPIをGObject-Introspectionツール経由で使うものだ。
残念ながら、これらのコールバックを他の言語に再バインドするのは極めて難しい。
そこで、新たなバインディングを設計することにした。言語自身やGLibの持つ非同期コールバック機能を活用するものだ。

\end{aosasect2}

%% \begin{aosasect2}{Object Readiness}
\begin{aosasect2}{オブジェクトのレディネス}
\label{sec.telepathy.readiness}

%% In a simple D-Bus API, such as the low-level Telepathy bindings, you
%% can start making method calls or receive signals on a D-Bus object
%% simply by creating a proxy object for it.  It's as simple as giving an
%% object path and interface name and getting started.
ローレベルTelepathyバインディングのようなシンプルなD-Bus APIでは、
メソッド呼び出しを開始したりD-Busオブジェクトのシグナルを受信したりするには
単にプロキシオブジェクトを作るだけでよい。
プロキシオブジェクトにオブジェクトへのパスとインターフェイス名を渡すだけで始められる。

%% However, in Telepathy's high-level API, we want our object proxies to
%% know what interface are available, we want common properties for the
%% object type to be retrieved (e.g., the channel type, target,
%% initiator), and we want to determine and track the object's state or
%% status (e.g., the connection status).
しかしTelepathyのハイレベルAPIの場合は、
どんなインターフェイスが使えるかをオブジェクトのプロキシが知っていて欲しいし、
オブジェクト型に共通するプロパティ(チャネル型やターゲット、イニシエータなど)も取得できて欲しい。
また、オブジェクトの状態や現状(接続状況など)も取得できるようにしたい。

%% Thus, the concept of \emph{readiness} exists for all proxy objects. By
%% making a method call on a proxy object, you are able to asynchronously
%% retrieve the state for that object and be notified when state is
%% retrieved and the object is ready for use.
そのために、すべてのプロキシオブジェクトに\emph{レディネス}という概念が存在する。
プロキシオブジェクト上のメソッドを呼び出すとそのオブジェクトの状態を非同期で取得できるようになり、
状態の取得を終えてオブジェクトが使えるようになった時点で通知される。

%% Since not all clients implement, or are interested in, all the
%% features of a given object, readiness for an object type is separated
%% into a number of possible features.  Each object implements a
%% \emph{core} feature, which will prepare crucial information about the
%% object (i.e., its \code{Interfaces} property and basic state), plus a
%% number of optional features for additional state, which might include
%% extra properties or state-tracking.  Specific examples of additional
%% features you can ready on various proxies are contact info,
%% capabilities, geolocation information, chat states (such as ``Escher
%% is typing{\ldots}'') and user avatars.
指定したオブジェクトの全機能をクライアントが実装しているとは限らないので、
オブジェクト型のレディネスはそのオブジェクトで使える機能とは切り離されている。
各オブジェクトは\emph{コア}機能を実装している。これは、そのオブジェクトに欠かせない情報
(\code{Interfaces}プロパティや基本状態)を準備するためのものだ。
そしてそれとは別にオプションの機能も実装しており、ここには追加のプロパティや状態の追跡などが含まれる。
各種プロキシ上で使える追加機能の例としては、
連絡先情報や位置情報、チャットのステータス(``Escher is typing{\ldots}''など)そしてユーザーのアバターなどがある。

%% For example, connection object proxies have:
たとえば、コネクションオブジェクトのプロキシが持つ機能は、次のようになる。

\begin{aosaitemize}

  %% \item a core feature which retrieves the interface and connection
  %%   status;
  \item インターフェイスや接続状態を取得するコア機能。

  %% \item features to retrieve the requestable channel classes and
  %%   support contact info; and
  \item リクエスト可能なチャネルのクラスやサポートする連絡先情報などを取得する機能。

  %% \item a feature to establish a connection and return ready when
  %%   connected.
  \item 接続を確立して、接続完了通知を返す機能。

\end{aosaitemize}

%% The programmer requests that the object is readied, providing a list
%% of features in which they are interested and a callback to call when
%% all of those features are ready. If all the features are already
%% ready, the callback can be called immediately, else the callback is
%% called once all the information for those features is retrieved.
プログラマーは、そのオブジェクトを使う準備が完了したかどうかを問い合わせる。
その際に、使いたい機能のリストと準備完了時に呼び出すコールバックを指定する。
すべての機能が既に使える状態の場合はコールバックが即時に呼び出されるが、
そうでない場合は、指定したすべての機能の準備が整った時点でコールバック呼び出される。

\end{aosasect2}

\end{aosasect1}

%% \begin{aosasect1}{Robustness}
\begin{aosasect1}{頑健性}

%% One of the key advantages of Telepathy is its robustness. The
%% components are modular, so a crash in one component should not bring
%% down the whole system.  Here are some of the features that make
%% Telepathy robust:
Telepathyの大きな利点のひとつが、その頑健性だ。
コンポーネントがモジュール化されているので、なにかひとつのコンポーネントが
クラッシュしたとしてもシステム全体がダウンするようなことがない。
Telepathyの頑健性の理由を以下にまとめる。

\begin{aosaitemize}

  %% \item The Account Manager and Channel Dispatcher can recover their
  %%   state.  When Mission Control (the single process that includes the
  %%   Account Manager and Channel Dispatcher) starts, it looks at the
  %%   names of services currently registered on the user's session bus.
  %%   Any Connections it finds that are associated with a known account
  %%   are reassociated with that account (rather than a new connection
  %%   being established), and running clients are queried for the list
  %%   of channels they're handling.
  \item Account ManagerとChannel Dispatcherが自身の状態を復元できること。
  Mission Control(Account ManagerとChannel Dispatcherを含む単一のプロセス)が立ち上がるときに、
  ユーザーのセッションバスに現在登録されているサービス名を調べる。
  既知のアカウントに関連づけられているコネクションが見つかれば
  (新たな接続を確立せずに)そのアカウントとの関連づけをもう一度行い、
  稼働中のクライアントには自分が扱っているチャネルのリストを問い合わせる。

  %% \item If a client disappears while a channel it's handling is open,
  %%   the Channel Dispatcher will respawn it and reissue the channel.
  \item 処理中のチャネルがオープンしているときにクライアントが消えてしまった場合は、
  Channel Dispatcherがクライアントをもう一度立ち上げてチャネルを再発行する。

    %% If a client repeatedly crashes the Channel Dispatcher can attempt
    %% to launch a different client, if available, or else it will close
    %% the channel (to prevent the client repeatedly crashing on data it
    %% can't handle).
    クライアントが頻繁にクラッシュする場合は、
    もし別のクライアントがあるのならChannel Dispatcherは別のクライアントを立ち上げることもできる。
    別のクライアントがない場合は、チャネルを閉じる
    (そして、扱うことのできないデータを渡されてクライアントがクラッシュしまくるのを防ぐ)。

    %% Text messages require acknowledgment before they will disappear
    %% from the list of pending messages. A client is only meant to
    %% acknowledge a message once it is sure the user has seen it (that
    %% is, displayed the message in a focused window). This way if the
    %% client crashes trying to render the message, the channel will
    %% still have the previously undisplayed message in the pending
    %% message queue.
    テキストメッセージの場合、受信確認があってからでないと処理待ちメッセージのリストからは消せない。
    クライアント側でメッセージの受信を確認できるのは、ユーザーがメッセージを見たとき
    (つまり、フォーカスのあたっているウィンドウにメッセージが表示されたとき)だけである。
    この方式にしておくと、もしメッセージのレンダリング中にクライアントがクラッシュしたとしても
    そのメッセージはまだ表示されていないものとして処理待ちキューに残る。

  %% \item If a Connection crashes, the Account Manager will respawn
  %%   it. Obviously the content of any stateful channels will be lost,
  %%   but it will only affect the Connections running in that process
  %%   and no others. Clients can monitor the state of the connections
  %%   and simply re-request information like the contact roster and any
  %%   stateless channels.
  \item コネクションがクラッシュした場合はAccount Managerがコネクションを立ち上げなおす。
  ステートフルなチャネルの内容は当然消えてしまうが、そのプロセスで稼働していたコネクションにしか影響は及ばず、
  他には影響しない。クライアントはコネクションの状態を監視できるので、
  連絡先リストやステートレスなチャネルなどに関しては単純に情報を再リクエストするだけでよい。

\end{aosaitemize}

\end{aosasect1}

%% \begin{aosasect1}{Extending Telepathy: Sidecars}
\begin{aosasect1}{Telepathyの拡張: サイドカー}

%% Although the Telepathy specification tries to cover a wide range of
%% features exported by communication protocols, some protocols are
%% themselves extensible\footnote{E.g., the Extensible Messaging and
%%  Presence Protocol (XMPP).}.  Telepathy's developers wanted to make
%% it possible extend your Telepathy connections to make use of such
%% extensions without having to extend the Telepathy specification
%% itself. This is done through the use of \emph{sidecars}.
Telepathyの仕様では、各種通信プロトコルが公開するさまざまな機能をできるだけカバーしようとしている。
しかし中には、プロトコル自体が拡張可能なものもある
\footnote{Extensible Messaging and Presence Protocol (XMPP)がその一例だ。}。
Telepathyの開発者たちは、Telepathyコネクションを拡張してそれに対応できるようにしようとした。
Telepathyの仕様自体はそのままにしておきたかったのだ。
これを実現するのが\emph{サイドカー}である。

%% Sidecars are typically implemented by plugins in a Connection Manager.
%% Clients call a method requesting a sidecar that implements a given
%% D-Bus interface.  For example, someone's implementation of XEP-0016
%% privacy lists might implement an interface named
%% \code{com.example.PrivacyLists}. The method then returns a D-Bus
%% object provided by the plugin, which should implement that interface
%% (and possibly others). The object exists alongside the main Connection
%% object (hence the name sidecar, like on a motorcycle).
サイドカーは、一般にConnection Managerのプラグインとして実装されている。
クライアントからは、指定したD-Busインターフェイスを実装したサイドカーをリクエストするメソッドを呼ぶ。
たとえば誰かがXEP-0016プライバシーリストを実装したとすると、そのインターフェイスは\code{com.example.PrivacyLists}
のようになるだろう。このメソッドは、プラグインが提供するD-Busメソッドを返す。
このオブジェクトは指定したインターフェイスを実装していなければ行けない(それ以外のインターフェイスも実装しているかもしれない)。
このオブジェクトは、メインのコネクションオブジェクトと並んで存在する
(だからこそサイドカーという名前にした。ちょうどバイクのサイドカーと同じようなものだ)。

%% \begin{aosabox}{The History of Sidecars}
\begin{aosabox}{サイドカーの歴史}

%% In the early days of Telepathy, the One Laptop Per Child project
%% needed to support custom XMPP extensions (XEPs) to share information
%% between devices. These were added directly to Telepathy-Gabble (the
%% XMPP Connection Manager), and exposed via undocumented interfaces on
%% the Connection object.  Eventually, with more developers wanting
%% support for specific XEPs which have no analogue in other
%% communications protocols, it was agreed that a more generic interface
%% for plugins was needed.
Telepathyが誕生して間もないころ、One Laptop Per Childプロジェクトが
カスタムXMPPエクステンション(XEP)を必要としていた。デバイス間で情報を共有するためのものだ。
そのエクステンションはTelepathy-Gabble (XMPP Connection Manager)
に直接追加され、コネクションオブジェクトの非公式なインターフェイスとして公開された。
後に、他の開発者たちも別のXEPへの対応を求めるようになった。
類似機能が他の通信プロトコルにはないようなものだ。
そんな経緯があって、プラグイン用のより汎用的なインターフェイスが必要だという結論に達したのだ。

\end{aosabox}

\end{aosasect1}

%% \begin{aosasect1}{A Brief Look Inside a Connection Manager}
\begin{aosasect1}{コネクションマネージャーの内部構造の概要}

%% Most Connection Managers are written using the C/GLib language
%% binding, and a number of high-level base classes have been developed
%% to make writing a Connection Manager easier.  As discussed previously,
%% D-Bus objects are published from software objects that implement a
%% number of software interfaces that map to D-Bus
%% interfaces. Telepathy-GLib provides base objects to implement the
%% Connection Manager, Connection and Channel objects. It also provides
%% an interface to implement a Channel Manager. Channel Managers are
%% factories that can be used by the \code{BaseConnection} to instantiate
%% and manage channel objects for publishing on the bus.
ほとんどのConnection ManagerはC/GLibバインディングを使って書かれており、
高レベルの基底クラス群の多くがConnection Managerを書きやすくするために開発されたものだ。
先に説明したとおり、D-Busオブジェクトを公開するのは
さまざまなインターフェイスを実装したソフトウェアオブジェクトであり、
それらのインターフェイスをD-Busインターフェイスとマップしている。
Telepathy-GLibは、Connection Managerやコネクションそしてチャネルを実装するための基底オブジェクトを提供する。
また、Channel Managerを実装するためのインターフェイスも用意する。
Channel Managerはファクトリーで、
\code{BaseConnection}によってインスタンス化され、
バス上に公開するチャネルオブジェクトを管理する。

%% The bindings also provide what are known as \emph{mixins}.  These can
%% be added to a class to provide additional functionality, abstract the
%% specification API and provide backwards compatibility for new and
%% deprecated versions of an API through one mechanism. The most commonly
%% used mixin is one that adds the D-Bus properties interface to an
%% object. There are also mixins to implement the
%% \code{ofdT.Connection.Interface.Contacts} and
%% \code{ofdT.Channel.Interface.Group} interfaces and mixins making it
%% possible to implement the old and new presence interfaces, and old and
%% new text message interfaces via one set of methods.
C/GLibバインディングは、いわゆる\emph{mixin}も提供する。
これをクラスに追加すると、付加機能を提供できる。
そしてAPIの仕様を抽象化し、新たなAPIが追加されたり過去のAPIが廃止されたりしても
互換性を保てるようになる。
最も使われているmixinは、D-Busプロパティのインターフェイスをオブジェクトに追加するものだ。
それ以外にも、\code{ofdT.Connection.Interface.Contacts}や\code{ofdT.Channel.Interface.Group}
インターフェイスを実装するmixinもあれば、新旧のプレゼンスインターフェイスや
新旧のテキストメッセージインターフェイスを同じメソッド群で実装できるようにするmixinもある。

%% \aosafigure{../images/telepathy/cm.eps}{Example Connection Manager Architecture}{fig.telepathy.manager}
\aosafigure{../images/telepathy/cm.eps}{コネクションマネージャーのアーキテクチャの例}{fig.telepathy.manager}

%% \begin{aosabox}{Using Mixins to Solve API Mistakes}
\begin{aosabox}{Mixinによる、APIの間違いの解決}

%% One place where mixins have been used to solve a mistake in the
%% Telepathy specification is the \code{TpPresenceMixin}.  The original
%% interface exposed by Telepathy
%% (\code{odfT.Connection.Interface.Presence}) was incredibly
%% complicated, hard to implement for both Connections and Clients, and
%% exposed functionality that was both nonexistent in most communications
%% protocols, and very rarely used in others. The interface was replaced
%% by a much simpler interface
%% (\code{odfT.Connection.Interface.SimplePresence}), which exposed all
%% the functionality that users cared about and had ever actually been
%% implemented in the connection managers.
mixinを使ってTelepathyの仕様バグを解決した例が\code{TpPresenceMixin}だ。
元々Telepathyが公開していたインターフェイス(\code{odfT.Connection.Interface.Presence})
は信じられないほど複雑で、コネクションとクライアントのどちらを実装するのも大変だった。
また、そもそもほとんどのプロトコルでコネクションにもクライアントにも存在しない機能を公開していたり、
片方では使うけれどももう一方ではほとんど使わないという機能を公開していたりした。
後にこのインターフェイスはもっとシンプルなもの(\code{odfT.Connection.Interface.SimplePresence})
に置き換えられた。これはユーザーが必要としていてConnection Managerで実際に実装されている機能は
すべて公開するものだ。

%% The presence mixin implements both interfaces on the Connection so
%% that legacy clients continue to work, but only at the functionality
%% level of the simpler interface.
プレゼンスmixinはコネクション上でのどちらのインターフェイスも実装しているので、
レガシーなクライアントでもドウサスル。しかし、機能面ではシンプルなインターフェイスのレベルにとどまる。

\end{aosabox}

\end{aosasect1}

%% \begin{aosasect1}{Lessons Learned}
\begin{aosasect1}{教訓}

%% Telepathy is an excellent example of how to build a modular, flexible
%% API on top of D-Bus. It shows how you can develop an extensible,
%% decoupled framework on top of D-Bus. One which requires no central
%% management daemon and allows components to be restartable, without
%% loss of data in any other component.  Telepathy also shows how you can
%% use D-Bus efficiently and effectively, minimizing the amount of
%% traffic you transmit on the bus.
Telepathyは、モジュール化された柔軟なAPIをD-Bus上に実装したすばらしい実例のひとつだ。
拡張性があって疎結合なフレームワークをD-Bus上で開発する方法を示している。
中央集権型のデーモンを使わずにコンポーネントを再起動できるし、
他のコンポーネントのデータを失うこともない。
Telepathyはまた、D-Busを効率的に使う方法も示している。
バス上をやりとりするデータのトラフィックを最小限に抑える方法がわかるだろう。

%% Telepathy's development has been iterative, improving its use of D-Bus
%% as time goes on. Mistakes were made, and lessons have been learned.
%% Here are some of the important things we learned in designing the
%% architecture of Telepathy:
Telepathyの開発は漸進的に行われており、時を経てD-Busの使い方も改善されている。
かつては間違いも犯したし、そこから得た教訓もあった。
Telepathyのアーキテクチャ設計で学んだ大切なことを、ここでいくつか紹介する。

\begin{aosadescription}

  %% \item{Use D-Bus properties; don't require dozens of small D-Bus
  %%   method calls to look up information.}  Every method call has a
  %%   round-trip time. Rather than making lots of individual calls
  %%   (e.g., \code{GetHandle}, \code{GetChannelType},
  %%   \code{GetInterfaces}) use D-Bus properties and return all the
  %%   information via a single call to \code{GetAll}.
  \item{D-Busのプロパティを使うこと。細かいD-Busメソッド呼び出しを大量に行わないと情報が得られないというのはやめる。}
  あらゆるメソッド呼び出しにはラウンドトリップタイムが発生する。
  個別の呼び出し(\code{GetHandle}、\code{GetChannelType}、\code{GetInterfaces}など)
  を大量に行うのではなく、D-Busプロパティを使ってすべての情報を一回の\code{GetAll}だけで返せるようにする。

  %% \item{Provide as much information as you can when announcing new
  %%   objects.}  The first thing clients used to do when they learned
  %%   about a new object was to request all of its properties to learn
  %%   whether they were even interested in the object. By including the
  %%   immutable properties of an object in the signal announcing the
  %%   object, most clients can determine their interest in the object
  %%   without making any method calls. Furthermore, if they are
  %%   interested in the object, they do not have to bother requesting
  %%   any of its immutable properties.
  \item{新たなオブジェクトをアナウンスするときには可能な限りの情報を提供する。}
  新たなオブジェクトを知ったクライアントが最初にするのは、そのすべてのプロパティをリクエストして
  そのオブジェクトで何ができるのかを知ることだ。オブジェクトを通知するシグナルの中に
  不変なプロパティを含めておけば、たいていのクライアントはそれだけで
  どんなことができるのかを判断できる。
  さらに、そのオブジェクトを実際に使うことになっても、
  不変なプロパティを改めてリクエストする手間が省ける。

  %% \item{The \code{Contacts} interface allows requesting information
  %%   from multiple interfaces at once.}  Rather than making numerous
  %%   \code{GetAll} calls to retrieve all the information for a contact,
  %%   the \code{Contacts} interface lets us request all the information
  %%   at once, saving a number of D-Bus round trips.
  \item{\code{Contacts}インターフェイスは、複数のインターフェイスからのリクエストを一度に受け付けられるようにする。}
  大量の\code{GetAll}呼び出しで連絡先の全情報を取得するのではなく、
  \code{Contacts}インターフェイスがすべての情報を一度に取得できるようにしておけば
  D-Busのラウンドトリップを減らせる。

  %% \item{Don't use abstractions that don't quite fit.}  Exposing the
  %%   contact roster and contact groups as channels implementing the
  %%   \code{Group} interface seemed like a good idea because it used
  %%   existing abstractions rather than requiring additional
  %%   interfaces. However, it made implementing clients difficult and
  %%   was ultimately not suitable.
  \item{すべきでないところでの抽象化はやめる。}
  \code{Group}インターフェイスを実装したチャネルで連絡先一覧や連絡先グループを
  公開するというのはよい考えに思える。新たなインターフェイスを追加せずに
  既存の抽象化を使えるからだ。
  しかし、クライアント側の実装は難しくなってしまうので、結局はあまり適しているとは言えない。

  %% \item{Ensure your API will meet your future needs.}  The original
  %%   channel requesting API was very rigid, only permitting very basic
  %%   channel requests. This did not meet our needs when needing to
  %%   request channels that required more information. This API had to
  %%   be replaced with one that had significantly more flexibility.
  \item{将来のニーズを満たせるようにAPIを設計する}
  当初のチャネルリクエストAPIは非常に柔軟性に欠け、ほんとうに基本的なチャネルリクエストしかできなかった。
  もっと多くの情報を必要とするチャネルリクエストをしたいというニーズは満たせないものだった。
  このAPIは書き直さざるを得なくなり、ずっと柔軟なものに置き換えられた。

\end{aosadescription}

\end{aosasect1}

\end{aosachapter}
